`env.BRANCH_NAME` 变为 `PR-1` [英] `env.BRANCH_NAME` becomes `PR-1`

问题描述

我们使用 Jenkins 管道和Github 多分支.

我在一个名为 feature/my1stfeature 的功能分支上工作.Jenkins 作业返回了正确的分支名称:

println(env.BRANCH_NAME) 返回 feature/my1stfeature.

但是，当我在 Github 中创建第一个拉取请求时

println(env.BRANCH_NAME) 返回 PR-01.

我当然想知道功能分支的名称.

如何解决?

解决方案

我不确定，但这可能与您的分支来源有关请参阅

所以基本上你有一个 PR 工作和一个 branch 工作.如果你有更多的触发器，你可能会有更多的工作.通常你使用:

• 公关工作更多地用于集成目的.它们可能发生在代理上的临时合并中.
• 分支作业用于发布目的.就像您不想在每次提交 PR 时发布.您只希望它仅在主分支或发布分支上通过发布过程，因此您可以这样做:

stage('Release') {什么时候 {beforeAgent true任何 {分支'主要';分支'释放/*'}}

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?

解决方案

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/*'
    }
  }

这篇关于`env.BRANCH_NAME` 变为 `PR-1`的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！