`env.BRANCH_NAME` becomes `PR-1`

Question

We use Jenkins pipeline & Github Multibranch.

I worked on a feature branch called feature/my1stfeature. The Jenkins job returned the proper branch name:

println(env.BRANCH_NAME) returned feature/my1stfeature.

However, as soon as I created my first pull-request in Github

println(env.BRANCH_NAME) returns PR-01.

I would of course like to have the name of the feature branch.

How to solve this?

Answer 1

For multibranch pipeline, you can get the branch name from any of below env variable -

1. If multibranch job is run for any branch -

BRANCH_NAME
For a multibranch project, this will be set to the name of the branch being built, 
for example in case you wish to deploy to production from master but not from feature branches; if corresponding to some kind of change request, the name is generally arbitrary (refer to CHANGE_ID and CHANGE_TARGET).

2. If multibranch job is run for any PR -

CHANGE_BRANCH
For a multibranch project corresponding to some kind of change request, 
this will be set to the name of the actual head on the source control system which may or may not be different from BRANCH_NAME. 
For example in GitHub or Bitbucket this would have the name of the origin branch whereas BRANCH_NAME would be something like PR-24.

CHANGE_TARGET
For a multibranch project corresponding to some kind of change request, this will be set to the target or base branch to which the change could be merged, if supported; else unset.

You can open ${YOUR_JENKINS_HOST}/env-vars.html page on your Jenkins master server to get a list of all environment variables listed on an HTML page.

Answer 2

I'm not sure, but this is likely something related to your Branch Sources See https://docs.cloudbees.com/docs/admin-resources/latest/multibranch-pipeline-template-syntax-guide/github

https://docs.cloudbees.com/docs/admin-resources/latest/plugins/github-branch-source

• So GitHub can react to commits to branches using gitHubBranchDiscovery
• It can also react to commits to Pull Requests using gitHubPullRequestDiscovery
• You can also react to both. Just be sure you're not reacting if you don't need to.
• You can react to other stuff as well. But let's not discuss that :)

I'm guessing you've either selected: Merging the pull request with the current target branch revision OR Both the current pull request revision and the pull request merged with the current target branch revision

Discover each pull request once with the discovered revision corresponding to the result of merging with the current revision of the target branch.

The current pull request revision

Discover each pull request once with the discovered revision corresponding to the pull request head revision without merging.

Both the current pull request revision and the pull request merged with the current target branch revision

Discover each pull request twice. The first discovered revision corresponds to the result of merging with the current revision of the target branch in each scan. The second parallel discovered revision corresponds to the pull request head revision without merging.

If you use 'Merging the pull request with the current target branch revision' then what ends up happening is that Jenkins creates another temporary (on the agent) branch in the following format PR-<PR-Number> and merges it with the target branch (main) and then goes through your stage

I couldn't find docs on how it gets named as PR-<PR-Number>, but that's what I'm seeing.

I specifically said 'another', because with Jenkins if you've used gitHubBranchDiscover then it would go through your Jenkinsfile again for the branch as well. Based on my understand what you want is: The current pull request revision

There are other combinations of setup that you can have, but just go and see your Branch Sources and validate if it's what you expect.

So basically you have a PR job and a branch job. You might have more jobs if you have more triggers. Normally you use:

• PR jobs are more used for Integration purposes. They can happen with a temp merge on the agent.
• branch jobs for Release purposes. Like you don't want to release upon every commit to a PR. You just want it to go through release process only on main or release branches hence you do:

stage('Release') {
  when {
    beforeAgent true
    anyOf {
      branch 'main'; branch 'release/*'
    }
  }