On each application you will find the settings page. In this article we will shortly walk through its content.
You can manage the permission settings of Wercker users on a per-application basis. Wercker offers three types of roles and permissions.
But what if you want to add someone who is not a Wercker user yet? You can use the same input field to send an invite email. When signed up, the user can directly access your application.
When the owner of an application is an organization you can only manage the permissions of teams. The owners team of an organization always has admin access.
Here you can set up deploy pipeline targets. Read more on deploying with Wercker at the following link.
Read more on deploying
Here you can set environment variables that are application-wide, these are available during every build and deploy.
This can be used for information that you don’t want to store in your repository (i.e. login information or keys).
Want to read more on environment variables, continue reading using the following link.
Here you manage SSH keys that you can leverage during builds and deploys. Read more on SSH Keys at the following link.
This is a grouped section of settings. Here you can adjust the following settings:
When you are in need of support and make contact with us, we may ask you to “activate support” on your application. This gives the Wercker team builds + deploys permissions, which allows us to see the details and debug the issue at hand.
Here you can clear the $WERCKER_CACHE_DIR. Read more about the Wercker cache directory at the following link.
When Wercker is not picking up your commits or Wercker shows a broken webhookwarning, you can hit the ‘Fix webhook’ button. Note that you need to be an admin on your repository in order to fix the webhook.
Here you can update the settings regarding how we checkout your code. For instance, if your builds fail during the get code step, you may need to reset the key used to check out the code or, in the case of a public application, you may want to configure your application to be checked out without an SSH key.
If you your application to be publicly viewable, anonymous users can view all builds. This is ideal when you are managing an open source application. Users can track the results of there commits before creating a Pull Request.
If you are creating a Wercker pipeline step your application needs to be public. Your published pipeline step will gain an extra page with details.
These settings are only available if your application is in a GitHub repository.
They configure how Wercker behaves when a user forks your repository and creates a pull request to merge a branch from that forked repository into a branch in your repository.
If the option Trigger runs for pull requests from forked repositories is set to on, Wercker will trigger a run whenever a pull request from a forked repository is created or updated. If it is set to off, pull requests from forked repositories will be ignored.
If you choose to trigger runs for pull requests from forked repositories then the option Pass secrets to runs for pull requests from forked repositories can be used to configure whether protected environment variables will be available to those runs.
If Pass secrets to runs for pull requests from forked repositories is set to on then protected environment variables will be available to the run in the normal way. If it is set to off, protected environment variables will be not available.
Here you can set branchnames for which Wercker should not trigger a build. This option supports a maximum of 10 items, and each input should be separated with a space.
Currently we support a simple wildcard to match against branches. The following formats are supported:
*. This will match every value.
*/foobar. This will match values that end with a specific value, but it doesn’t matter what the beginning is.
foobar/*. This will match values that begin with a specific value, but it doesn’t matter what the end is.
The following situations are not supported:
By default all applications with a GitHub repository already have one branchname prefilled. The branchname gh-pages is ignored for users who deploy to GitHub pages. If you don’t make use of GitHub pages you can remove or ignore this setting.
This section is only visible when the owner of an application is an organization. Normally the owner’s GitHub or Bitbucket credentials are used for setting the status of builds and to make various API calls.
An organization doesn’t have the option to connect to GitHub or Bitbucket, so you can select an organization member whose credentials will be used.
Here you can transfer the ownership of an application to another wercker user or an organization.
We give an extra warning when you’re about to transfer ownership, because at this moment it is not possible to transfer an application back to a user or to another organization.
Here you can choose to delete your application and all its settings. Clicking this button will delete your application, all its pipeline executions, environment variables and settings. There is no recovering from this.