Environment Variables¶
Pre-defined Environment Variables¶
We set the following environment variables by default:
SCRUTINIZER | true |
CI | true |
DISPLAY | :99 |
SCRUTINIZER_BRANCH | The branch that this inspection belongs to. For pull requests, this equals the target branch. |
SCRUTINIZER_PR_NUMBER | The number of the pull request if the inspection refers to a pull request, otherwise not set. |
SCRUTINIZER_PR_SOURCE_BRANCH | The source branch if the inspection refers to a pull request, otherwise not set |
SCRUTINIZER_SHA1 | The revision of the head commit. For pull requests, this equals the merge commit sha on GitHub, and the head sha of the source branch on Bitbucket. |
SCRUTINIZER_INSPECTION_UUID | The UUID of the inspection. |
SCRUTINIZER_PROJECT | Your project's qualified name, f.e. g/scrutinizer-ci/worker for GitHub hosted projects, or
b/scrutinizer-ci/worker for projects hosted on Bitbucket. |
SCRUTINIZER_NODE_NAME | The name of the node in which the build is currently running. |
Defining Custom Environment Variables¶
You can define environment variables via the configuration:
build:
# Variables for all nodes
environment:
variables:
FOO: 'BAR123'
nodes:
functional-tests:
# Variables for just a single node
environment:
variables:
FOO: 'BAR345'
Scrutinizer automatically makes sure that these variables are propagated to all relevant processes. For example, if you are using Apache2, we automatically add these variables to the virtual host configuration.
Keeping Sensitive Variables Safe¶
If you would like to keep sensitive variables outside of your repository like AWS credentials for deployment for example, we recommend to add them on the website:
alt: | Repository Configuration that shows AWS access credentials |
---|
We will automatically merge this configuration with the .scrutinizer.yml
in your repository.
Read more about our configuration best practices to learn more about the pros and cons of where to keep your configuration.
Sharing Variables between Projects¶
If you would like to share environment variables across projects, you can define a build
in
your global configuration. Then, it will automatically
be inherited by all projects that use this configuration.