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

[Peter Roth]

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

image:
  name: $BUILD_IMAGE_NAME:$BUILD_IMAGE_VERSION

...

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.

[ktomk]

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 ):

---
pipelines:
  custom:
    lint-php-5.3:
      - step: &lint-php53
          image: php:5.3
          script:
            - lib/pipelines/lint.sh
    lint-php-7.4:
      - step: &lint-php74
          <<: *lint-php53
          image: php:7.4
    lint-php:
      - 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).