Environment variables can be added on an organization, an application and a pipeline. When running the pipeline environment variables will be merged from these 3 targets into a unified list that is made available to your pipeline. In case of duplicate names lower level ones override the higher level ones (for instance
NODE_ENV in pipeline will override
NODE_ENV in an application).
Environment variables include text fields and SSH keys.
First choose where you want to create your environment variable: on the organization, on the application or on the pipeline.
Creating a new environment variable is as simple as filling in a name, value and hitting Add. The next pipeline run you will trigger now has the environment variable available in its pipeline.
If you check the
Protected checkbox the value can only be read out in the actual build and won’t be made visible anywhere in the interface. Use this to protect sensitive data such as passwords. [Read more on protected env vars]()
All environment variable that are available need to be used by adding a
$ character. For instance a
SLACK_URL environment variable can be used in your wercker.yml as
An example of how you to use a environment variable with our Slack notify step:
build: after-steps: - slack-notifier: url: $SLACK_URL channel: notifications username: myamazingbotname
Another common type of information used during deploys (but also during builds) are SSH key pairs. Wercker can generate them for you and will only expose the public part of the pair via the interface. Wercker will generate two environment variables for you ending with
_PUBLIC. The private SSH key is used in the build and you should copy the public one to the destination.
For instance, if you created an
SSH key pair to use as a bitbucket deploy key, you may want to name the variable
DEPLOY_KEY. During the pipeline run you will now have two environment variables: