Provide env variable for branch name targeted by pull request
r
ruffsl
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:
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.
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. 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.CCI-I-894
P
Pradeep
Please implement this feature. This is really required to do the path filtering specific to the base branches for PR builds.
S
Sebastián Iglesias
In serious need of this feature, I need to run a specific test suite when a PR gets opened from one specific branch to another specific branch. Please consider implementing it!!
Ville Lahdenvuo
Please add
pipeline.git.base_branch
it should be easy!Tom Piddock
Now three years later this is still a highly sought after variable and not having a response from Circle CI is a little aggravating.
Rob Witman
This is one of the highest ranked issues that I have come across, yet the thread is mostly dead. Is this something CircleCI will ever look into? Considering the connection to Github is already being made, it would appear as something that could be added without a lot of work and yet the gain would be large.
The GHPR Orb is a solid work around, except that it is no longer being maintained. It also has an issue where it will fail if it is called on a branch without an open PR. That then requires some conditional logic to avoid failing your whole build system if you happen to allow Workflows on branches without a PR.
Merged in a post:
CIRCLE_TARGET_BRANCH env var
M
Markus Padourek
It would be nice to be able to see which branch the current PR is targeted and it seems there have been a few people so far requesting this feature,: https://discuss.circleci.com/t/create-a-circle-target-branch-envar/10022, https://discuss.circleci.com/t/add-environment-varible-circle-pr-base-branch/6189, and I have seen more places where this feature has been mentioned. Other CIs provide this information and it would also make it easier to fulfill use-cases like: https://circleci.com/ideas/?idea=CCI-I-208 in a very generic manner.
Our specific use case would be, I want to be able get the full commit range range of the current PR, so even when a new commit is pushed that triggers a new build it would show the full commit range from the first commit and not just the range form the previous build/commit.
CCI-I-585
C
Celestine Kao
If you're using GitHub as your VCS, the ghpr orb has a command that sets the target branch in the env var GITHUB_PR_BASE_BRANCH.
A
Antonio De Almeida
Also, expand my comment, it's also incredibly useful for when you're doing partial builds that need to be persisted and uses your git branch data like Nx work flows.
nx depends heavily on knowing (via git) what has changed and which pieces of the apps need to be built and tested.
A
Antonio De Almeida
Well, we could always look at what's already done out there and makes sense.
On Azure DevOps you have System.PullRequest which is only defined if it's a PR triggered build and not a CI build.Based off of these "sets of variables" that get declared when it's a PR build, you can do some things and fetch data like:.TargetBranch and so forth.
Scroll down a little at the link below to find the PR related variables.
E
Emil
+1, I wouldn't mind having it as an ENV, I think it makes sense. Also, I would rather have this feature quickly, than having it thoroughly designed and implemented in a future version, with no access for people not able to switch to the new version.
Also, I don't see a problem with adding "another magical ENV" since:1.) It's not "magical" in the sense that some users might have created user defined ENV:s that might conflict with new variables prefixed with ENV:s. I think it's unlikely that users prefix their custom values with CIRCLE_2.) I don't think the total amount of ENV:s today is a problem.
Furthermore, I believe it would be less confusing if it was provided as an ENV since we already have one ENV (CIRCLE_BRANCH) which is confusing to some users since TRAVIS_BRANCH provides the ENV as "the target branch". Having two similarly named ENV:s might be slightly confusing, yes, but it forces you to consider what the ENV:s represent, instead of misleading some users (e.g. Travis users) into thinking that the only CIRCLE_BRANCH variable does the same thing as TRAVIS_BRANCH does.
Load More
→