Variables are configured as environment variables in the build container. You can access the variables from the bitbucket-pipelines.yml file or any script that you invoke by referring to them in the following way:
where AWS_SECRET is the name of the variable.
Pipelines provides a set of default variables that are available for builds, and can be used in scripts.
You can override the default variables by specifying a variable with the same name.
Default value is true. Gets set whenever a pipeline runs.
The unique identifier for a build. It increments with each build and can be used to create unique artifact names.
The absolute path of the directory that the repository is cloned into within the Docker container.
The commit hash of a commit that kicked off the build.
The name of the workspace in which the repository lives.
The URL-friendly version of a repository name. For more information, see What is a slug?.
The UUID of the repository.
The full name of the repository (everything that comes after http://bitbucket.org/).
The source branch. This value is only available on branches.
Not available for builds against tags, or custom pipelines.
The tag of a commit that kicked off the build. This value is only available on tags.
Not available for builds against branches.
For use with Mercurial projects.
Zero-based index of the current step in the group, for example: 0, 1, 2, …
Not available outside a parallel step.
Total number of steps in the group, for example: 5.
This variable is only available for pipelines running on Bitbucket Cloud and the Linux Docker Pipelines runner.
You can add, edit, or remove variables at the workspace, repository, and deployment environment levels. If you use the same name as an existing variable, you can override it. The order of overrides is Deployment > Repository > Workspace > Default variables. Each deployment environment is independent so you can use the same variable name with different values for each environment.
Before you begin bear in mind that:
Names can only contain ASCII letters, digits and underscores
Names are case-sensitive
Names can't start with a digit
Variables defined by the shell should not be used. You can find them by using a step with the command printenv.
Do not configure a pipeline variable with the name PATH or you might break all the pipeline steps. This happens because the shell uses PATH to find commands, so if you replace its usual list of locations then commands like docker won't work any more.
Variables specified for a workspace can be accessed from all repositories that belong to the workspace. You must be an administrator to manage workspace variables.
From your profile. avatar, select a workspace.
Select the Settings cog on the top navigation bar.
Select Workspace settings from the Settings dropdown menu.
In the menu on the left, go to Pipelines > Workspace variables.
Workspaces variables can be overridden by repository variables.
Workspace variables can be accessed by all users with the write permission for any repository (private or public) that belongs to the team or account.
You must be an administrator of a workspace or a repository to manage variables respectively.
Pipelines variables added at the repository level can be used by any user who has write access in the repository. To access and configure the repository variables, the user must be an admin of that repository.
From the repository, you can manage repository variables in Repository settings > Pipelines > Repository variables. Note: Repository variables override team variables.
You can also define variables so that they can only be used in a specific deployment environment.
From the repository, you can manage deployment variables in Repository settings > Pipelines > Deployments. Note: Deployment variables override both team and repository variables, and are unique to each environment.
# Deployment variables will only work within deployment steps in bitbucket-pipelines.yaml
name: Deploy to Test
- echo $DEPLOYMENT_VARIABLE
You can secure a variable, which means it can be used in your scripts but its value will be hidden in the build logs (see example below). If you want to edit a secure variable, you can only give it a new value or delete it. Secure variables are stored as encrypted values. Click the padlock to secure the variable.
Secured variable masking
Pipelines masks secure variables so they are not disclosed to your team members viewing build logs. If a value matching a secured variable appears in the logs, Pipelines will replace it with $VARIABLE_NAME.
This can lead to confusion about whether secured variables are working properly, so here's an example of how it works:
First, we have created a secure variable, MY_HIDDEN_NUMBER, with a value of 5.
The value of the variable can be used by the script, but will not be revealed in the logs. It is replaced with the name of the variable, $MY_HIDDEN_NUMBER.
Pipelines masks all occurrences of a secure variable's value in your log files, regardless of how that output was generated.
If you have secure variable value set to a common word, that word will be replaced with the variable name anywhere it appears in the log file. Secured variables are designed to be used for unique authentication tokens and passwords and so are unlikely to be also used in clear text.
Pipelines also matches some basic encodings of the variable value, like URL encoding, to prevent variables being displayed when used in URLs.