Conditioning Docker Image via base branch name from PR

I’m working on a project that builds from an upstream project with distro releases. Our project tracks each distro by splitting off <distro>-devel branches for each new released distro, while our master branch only follows upstream master development.

I’d like to use the PR base branch name (the branch a PR is intended to be merged into) to conditionally switch the docker image tag to be used by the docker executor. A mock example:

executors:
  docker_exec:
    parameters:
      tag_name:
        type: string
        default: master
    docker:
      - image: org_name/repo_name:<< parameters.tag_name >>

jobs:
  debug_build:
    executor: docker_exec
    parameters:
      tag_name: $CIRCLE_TARGET_BRANCH
    environment:
      CMAKE_BUILD_TYPE: "Debug"
    steps:
      - checkout_source
      - build_source
      - test_source
      - report_coverage
  release_build:
    executor: docker_exec
    parameters:
      tag_name: $CIRCLE_TARGET_BRANCH
    environment:
      CMAKE_BUILD_TYPE: "Release"
    steps:
      - checkout_source
      - build_source
      - test_source

workflows:
  version: 2
  build-test:
    jobs:
      - debug_build
      - release_build

In this way, pull requests and branch updates are built using the image tag from the docker registry that matches the destination branch name. E.g. external PRs targeting our local repos foo-devel branch will be tested using the docker image tagged as org_name/repo_name:foo-devel.
Is there a way I can achieve this? Thank you.


References

1 Like

Case example: https://circleci.com/gh/ruffsl/navigation2/89

This PR originated from branch foo, but was destined for branch crystal-devel, however $CIRCLE_BRANCH resolved to foo instead of crystal-devel, thus build failing from incorrect tag.

Perhaps as a workaround: is there any way to update and pass parameters from one job to the next?

Would it then be possible to prepend an intermediate job to the workflow that introspects the github API for the target branch name of the PR, and then sets that string as a parameter to be used in the flowing jobs to enable conditioning of the docker image used by the later executor dynamically?

This really sounds like something the CI itself should handle.


Yep, you can use workspaces, which preserve files/folders between jobs. You could pass data in a file using this approach.

I don’t think preserving any files/folders between jobs could result in the effect of conditionally switching the docker tag any consecutive job’s docker executer uses to run steps. The conditional required here must be usable in the config before even the first step of the consecutive job’s is able to run, given the selection of the executer precedes any step that could read the file system. That why I wondered if parameters could be dynamicly set and persist between jobs.

From reading the docs and related posts, this does not seem currently possible with workspaces alone:

Using paramaters in executors seems to be a step in that direction, yet I’m left wondering how to dynamicly set these perimeters from logic in the config used to introspect the target branch name, given that circleci does not just provide it at startup?

https://circleci.com/docs/2.0/reusing-config/#using-parameters-in-executors

Parameters seem to have scope, and so setting the value of a paramaters from inside one job would not change the global one passed to the next job. There also doesn’t seem to be a way to conditionally set a parameter, i.e. not to a constant value.

I’ve submitted an feature request to the ideas portal. Please see idea CCI-I-894

Provide env variable for branch name targeted by pull request

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.