Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Is it possible to use a repository variable as the build image in bitbucket-pipelines.yml?

For example, I would like to define a bitbucket-pipelines.yml file with the image specified such as:



My real goal is to improve the DRYness of all of my bitbucket-pipelines.yml files that I have in 100s of software repos. 

Defining the version in one place will be an improvement over what I am doing now which is copy-pasting this image line in all of these repositories and causing me to use the "latest" version to avoid having to change this image version whenever there is a fix/improvement made to the build image.

The real goal is to write this bitbucket-pipelines.yml file in one place and share it with many projects (I'll actually need a few versions, one for maven-jdk8, one for maven-jdk-11, one for sbt, one for python, etc).  This will improve the DRYness and improve the Uniformity between all my repositories.

1 answer

AFAIK me personally has never used variable substitution at that stage - but this should be easy to test, you would need a repository variables for that. IIRC I've used variable substitution for image logins (private docker registries) and it worked. So it might be it works already out of the box, just let me know if.

If not:

In case you only change the image name but the rest remains the YAML notation of "<<:" might come in handy. You can then re-use everything only change the part that changes.

Here is an example for that which uses the same pipeline definition but just different PHP versions (images) for it (valid excerpt from a bitbucket-pipelines.yml in my pipelines project ):

- step: &lint-php53
image: php:5.3
- lib/pipelines/
- step: &lint-php74
<<: *lint-php53
image: php:7.4
- step: *lint-php53
- step: *lint-php74

 This shows how to make use of anchors and for mixins.

The first custom pipeline defines as-is but provides an alias name ("lint-php53").

The second custom pipeline defines another alias name ("lint-php74") while re-using everything from the first pipeline but overriding the image name.

The third pipeline just runs the two other pipelines one after the other.

Maybe this example is of help to what you try to address in case variables are not working out well. Repository variables might become cumbersome to maintain over time, changes in the .yml file are much more direct to test.

Additionally: If this is across multiple repositories, consider to generate the bitbucket-pipelines.yml file in a standard procedure (with updates) from a template file and have a process (for example a pipeline) to distribute updates to target systems (e.g. creating pull-requests or if the process is stable, just distribute by applying change-sets in git automatically).

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

Admins, notify your Jira instance of system-wide changes with the new admin announcement banner

Hi All! We’re excited to share the launch of an announcement banner that lets Jira site administrators communicate directly to their users across their  Jira Cloud instance.  ...

753 views 17 21
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you