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
    8 May 10:22am

    If your PC is getting slower & tried everything or selling out your system, then the last option remain is to wipe out everything. However, before wipe out the important documents you must have the back-up of all the important stuff that you have on your PC. Here you will see bast ways to can't factory reset windows 10 pc. By this, you have an option of partially clean up your PC or a complete wipe.

    There are therefore many reasons to reset Windows 10; you might facing slow speed or maybe selling your PC so that no data remain left on your PC. I have noticed the efficiency of your PC is improved therefore much after a factory reset. Forever create sure you have a backup of all your important data before taking any further step; otherwise, you may lose data forever.

    can't factory reset windows 10 pc

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    28 Apr 02:57pm

    File Explorer is a helpful tool for customers to access files and folders on your hard drive. However, there are some customers reported that their file explorer is not responding when they browse files saved on the hard drive, which is really annoying. This article will give customers with nine methods to fix the file explorer not responding Windows 10 issue.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    13 Jan 10:53pm

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Nov, 2019 08:12am

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Nov, 2019 08:11am

    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.

    https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables

     

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Nov, 2019 08:59am

    +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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    30 Oct, 2019 12:36pm

    Please!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    8 Oct, 2019 03:38pm

    Yes please. My use case is caching on a per-branch basis. Unless I missed something there is no easy way to do that as the {{ .Branch }} tag on the cache will not have the right branch name for PRs on that branch.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    21 Aug, 2019 06:39am

    @Nathan that would only move the issue, then external tooling can not detect the CI context without the user setting environment variables based on your other vars. I'm just using my library as an example, I understand you can't guarantee it will work with it.

     

    It just makes it hard for external code to get the CI context in a standard way from the environment.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug, 2019 09:49pm

    How much would pipeline variables extend to supply job info? Could this provide context into the executor as well? e.g. for docker images used by docker exec https://discuss.circleci.com/t/introspect-image-info-from-inside-docker-executor/31620/7

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug, 2019 05:27pm
    @Nathan Dintenfass The type of pattern pipeline parameters do not lend themselves to is shell expansion of alternative values for variables e.g. BUILD_VERSION=${CIRCLE_TAG:-${CIRCLE_PR_NUM:-${CIRCLE_BRANCH}}} By using the pipeline parameters, consumes will need to first explicitly define multiple environment variables and then perform the above via subsequent steps. This is likely quite a lot of boilerplate. Similarly if someone has written tooling using other languages to be executed, either they need to now build a CLI accepting arguments or set env variables beforehand in order to consume. I think the solution is a start, and it would partially solve the need, just needs standard pattern/orb/common step to convert multiple items from pipeline parameters to environment variables for subsequent steps would avoid a lot of boilerplate duplication for users.
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug, 2019 05:25pm

    You can always pass them into the environment explicitly, so that shouldn't be a problem -- support for `get-ci-env` is not something we can guarantee, but getting pipeline variables into runtime env vars will be straightforward. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug, 2019 03:36pm

    @Nathan, that would satisfy our need for this and I feel like most people in this thread's needs. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug, 2019 06:56am

    @Nathan this would not solve the issue for me because external tooling (like get-ci-env) won't be able to access those variables easily right?

    Please reconsider following the convention of environment variables.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Aug, 2019 01:37pm

    @Nathan Dintenfass this just looks like a renaming of the environment variables you all are currently supplying. 

     

    The crux of this issue, and why you did not provide `CIRCLE_PR_BRANCH` to begin with is because instead of running a job separately for both branch and PR, circle is attempting to intelligently determine if a branch matching a PR has already been run. It then attaches this branch build to the PR in order to conserve resources. It turns out this is not intelligent, reason being that you may require the use of different variables in your PR pipeline than your branch pipeline (one example being that you want to run specific behavior only against PRs branched off master. you can only do this if you know the `CIRCLE_PR_BRANCH`... which did not exist on the branch build, so it fails... which circle now attaches to the PR, in a failed state, while a rerun causes it to work). 

     

    The issue of not having `CIRCLE_PR_BRANCH` available is actually a symptom of the poor decision to attempt to attach existing branch builds to PRs with matching branches. This should not be done. A new build should be run for the PR. Since you're already supplying `CIRCLE_PR_BRANCH` to builds made fresh against PR's, this symptom will be fixed as a ride-along. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Aug, 2019 10:41am

    how to access `pipelines variables` in nodejs?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Aug, 2019 09:58am

    We are designing a way to get this information, though instead of putting the in environment variables we are looking at providing them as pipeline-level variables, so you can use them more flexibly in your config (and so that we don't have to push more "magical" environment variables into your runtime without you wanting them there). I've put up a quick sketch of what this might look like here: https://circleci-public.github.io/pipeline-preview-docs/pipeline_variables_overview.html 

     

    Would that satisfy this need?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    16 Aug, 2019 09:14am

    It should be a must to have a simple way to extract the branches related to a PR.  Both the original and the targeted branch should be in the environmental variables such as CIRCLE_PR_ORIGIN and CIRCLE_PR_TARGET

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 Aug, 2019 08:29am

    Given that github already provides this information in a PR event notification (https://developer.github.com/v3/activity/events/types/#pullrequestevent) it seems like it should just be a case of inspecting for pull_request.base.ref and using the value

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    1 Aug, 2019 08:25am

    This would enable jobs that provide alerts/warnings based on issues being introduced by a given PR need to be able to establish what the baseline is. Currently these have to default to origin/master, but for any repository with more than one target branch this will result in the wrong behaviour.

  • Load older comments