Allow using environment variables in the Docker image name

Issue #13014 open
created an issue

We have a setup where the docker hub builds our agent container for use with Bitbucket Pipelines. However I would like the Pipelines build to match the image which is tagged with the branch name. Currently using $BITBUCKET_BRANCH in my image name is not allowed.

Comments (17)

  1. Steven Vaccarella staff

    That sounds like a useful enhancement to me.

    I'm not sure if it would work for your use case, but are you aware that there is some limited support for specifying different images for some branches by defining a "branches" section in the configuration file? Have a look at the sample config file here:

    Obviously this is not going to work for you if you are building a large number of branches and you need every branch to have a different image, but if you just have a handful of different images then it might be feasible to define a separate section of the config file for each image. And you can define patterns if you need multiple branches to use the same image.

  2. RichardS reporter

    Yeah, I was thinking that each feature branch could run from its own image. It's quite a small use case since the image will be unchanged most of the time and running from the image built from master should be fine most of the time anyway but I'll keep the ticket open as a feature request for the future.

  3. Matt Ryall staff

    Quick update on this ticket - it is still under consideration for future work, but not something we have scheduled right now.

    This is more important now that we can build Docker containers in Pipelines (#12790), because you can't use that container as a service in a subsequent step unless the tag name is hard-coded.

    However, this issue will be largely mitigated by docker run support (#14145) which is on our backlog for later this year.

    Personally, I'd like it if Pipelines variables were replaced throughout the YAML file by default, rather than just being available as environment variables inside the container. It would make them more flexible, but also potentially a little confusing from the two different ways they are interpolated (some at parse time by the config parser, and some at build execution time by the shell).

  4. Hamin Mousavi

    Typical use-case for me would be something like:

      name: $AWS_ACCOUNT_ID.dkr.ecr.$$IMAGE_NAME
        access-key: $AWS_ACCESS_KEY_ID
        secret-key: $AWS_SECRET_ACCESS_KEY
  5. Alex Whiteside

    Having this issue too. We are moving from CircleCI and have a similar use case to @Hamin Mousavi

    We build the image then want to test it. The only work around we've found is to have to source the base Dockerfile and then run all the commands again. It's a bit of a nightmare so hoping to see a fix soon.

  6. Log in to comment