# Conditioning Docker Image via base branch name from PR **URL:** \ **Category:** Build Environment\ **Tags:** docker\ **Created:** [February 16, 2019, 3:53am UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426 "2019-02-16T03:53:17Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ruffsl](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/ruffsl/32/21229_2.png) [@ruffsl](https://discuss.circleci.com/u/ruffsl)\ **Post date:** [February 16, 2019, 3:53am UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/1 "2019-02-16T03:53:17Z")
I’m working on a project that builds from an upstream project with distro releases. Our project tracks each distro by splitting off `-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: ```yaml 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 [https://discuss.circleci.com/t/create-a-circle-target-branch-envar/10022/2](https://discuss.circleci.com/t/create-a-circle-target-branch-envar/10022/2) [https://discuss.circleci.com/t/only-build-pull-requests-targetting-specific-branch/6082](https://discuss.circleci.com/t/only-build-pull-requests-targetting-specific-branch/6082) [https://discuss.circleci.com/t/need-a-way-to-get-dest-branch-on-pull-request-buulds/954](https://discuss.circleci.com/t/need-a-way-to-get-dest-branch-on-pull-request-buulds/954) > [@Build only pull request to a specific branch](https://discuss.circleci.com/t/build-only-pull-request-to-a-specific-branch/903): > > Is there a way for me to build (and thus run my deployment) on branch X only when it has a pull request to branch master ? (I want my trigger for the build + deployment will be pull request to master from branch Release-x.y.z) ---
**Author:** ![ruffsl](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/ruffsl/32/21229_2.png) [@ruffsl](https://discuss.circleci.com/u/ruffsl)\ **Post date:** [February 16, 2019, 4:20am UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/2 "2019-02-16T04:20:47Z")
Case example: [https://circleci.com/gh/ruffsl/navigation2/89](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. ---
**Author:** ![ruffsl](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/ruffsl/32/21229_2.png) [@ruffsl](https://discuss.circleci.com/u/ruffsl)\ **Post date:** [February 19, 2019, 6:28pm UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/3 "2019-02-19T18:28:50Z")
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. * * * [https://discuss.circleci.com/t/how-to-pass-information-between-jobs-in-a-workflow/17988](https://discuss.circleci.com/t/how-to-pass-information-between-jobs-in-a-workflow/17988) ---
**Author:** ![halfer](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/halfer/32/9083_2.png) [@halfer](https://discuss.circleci.com/u/halfer)\ **Post date:** [February 20, 2019, 7:38am UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/4 "2019-02-20T07:38:33Z")
> [@ruffsl](#): > > Perhaps as a workaround: is there any way to update and pass parameters from one job to the next? Yep, you can use workspaces, which preserve files/folders between jobs. You could pass data in a file using this approach. ---
**Author:** ![ruffsl](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/ruffsl/32/21229_2.png) [@ruffsl](https://discuss.circleci.com/u/ruffsl)\ **Post date:** [February 20, 2019, 5:44pm UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/5 "2019-02-20T17:44:46Z")
> [@halfer](#): > > 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: [https://discuss.circleci.com/t/passing-variables-from-workflows-to-jobs-aka-parameterising-jobs/22328](https://discuss.circleci.com/t/passing-variables-from-workflows-to-jobs-aka-parameterising-jobs/22328) [https://discuss.circleci.com/t/how-to-pass-information-between-jobs-in-a-workflow/17988](https://discuss.circleci.com/t/how-to-pass-information-between-jobs-in-a-workflow/17988) 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](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. ---
**Author:** ![ruffsl](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/ruffsl/32/21229_2.png) [@ruffsl](https://discuss.circleci.com/u/ruffsl)\ **Post date:** [February 20, 2019, 10:08pm UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/6 "2019-02-20T22:08:47Z")
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 > **[Ideas](https://circleci.com/ideas/?idea=CCI-I-894)** > > Submit ideas for CircleCI and vote for ideas others have submitted. ---
**Author:** ![system](https://global.discourse-cdn.com/circleci/original/3X/5/1/511608acda8e85906e15909b57bd0a46c1dbe291.png) [@system](https://discuss.circleci.com/u/system)\ **Post date:** [March 2, 2019, 10:08pm UTC](https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426/7 "2019-03-02T22:08:48Z")
Closed on March 2, 2019, 10:08pm UTC This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.