CircleCI Ideas

Provide env variable for branch name targeted by pull request

For many reasons, it is necessary to determine the branch target pull request that triggered the current workflow. This has been a frequently requested feature, and has cropped up on the discuss.circleci site in numinous requests and formats. 

 

Example:

Conditioning the selected image tag used by the docker executor via base branch name from PR, given that this is otherwise intractable given the otherwise lack of propagating such conditional logic to a jobs executed prior to the job being able to even run.
Please see the reference here:

https://discuss.circleci.com/t/conditioning-docker-image-via-base-branch-name-from-pr/28426

 

Issue:

Currently, as of CircleCi 2.0, no environment variables provide a basic means to aquise the branch name targeted by a pull request, be it from a forked repository or internal from the local repo.  

https://circleci.com/docs/2.0/env-vars/

 

The closest contenders include the `CIRCLECI_BRANCH` that for pull requests, instead returns the name of branch intended to be merged from with the new commits, not the base branch for which the commits would like to be merged into. Additionally, `CIRCLE_PULL_REQUEST` only contains the URL of the associated pull request, which has no-or-limited utility for the case example described above, given the branch name would first need to be parsed from the URL before useable.

 

Alternatives:

 

If we take a comparative look at Travis, provided is the `TRAVIS_BRANCH` env variable that returns the the branch targeted by the pull request if triggered by such a PR. 

https://docs.travis-ci.com/user/environment-variables/

 

TRAVIS_BRANCH:

  • for push builds, or builds not triggered by a pull request, this is the name of the branch.
  • for builds triggered by a pull request this is the name of the branch targeted by the pull request.
  • for builds triggered by a tag, this is the same as the name of the tag (TRAVIS_TAG).

 

Proposal:

Given the current pattern of available variables from CircleCI, including:

 

CIRCLE_PR_NUMBER Integer The number of the associated GitHub or Bitbucket pull request. Only available on forked PRs.
CIRCLE_PR_REPONAME String The name of the GitHub or Bitbucket repository where the pull request was created. Only available on forked PRs.
CIRCLE_PR_USERNAME String The GitHub or Bitbucket username of the user who created the pull request. Only available on forked PRs.

 

I'd suggest adding `CIRCLE_PR_BRANCH` that provides such a feature as follows:

 

CIRCLE_PR_BRANCH String The target branch name in the GitHub or Bitbucket repository where the pull request was created. Only available on forked PRs.

 

Alternatively, it might be nice to follow the logical switching of `TRAVIS_BRANCH` to allow for in branch commits to use the same conditioning logic as described in the case example link without compilation then the job trigger does not arise from a PR.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Feb 20 2019
  • New
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    28 Mar 10:04

    Yes please! CircleCI is the only CI provider blocking me from adding target branch information to my Node package: https://github.com/Siilwyn/get-ci-env/issues/3

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    13 May 18:10

    I'd think that this would be a pretty quick win.

    I'm currently doing some comparing against master, finding the merge-base commit with `git merge-base origin/master HEAD`. It would be great if I could change that to `git merge-base $CIRCLE_PR_BRANCH HEAD` so that I could use the same job on merges to our production branch.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Jun 17:21

    How is this not a thing yet?