只构建已经推送到的 Git 分支 [英] Build only the Git branch that has been pushed to

问题描述

我有一份 Jenkins 工作来构建我的 GitHub 存储库的 master 分支.当我向 master 推送提交时，它会很好地触发，我对此感到非常高兴.

I have a Jenkins job to build the master branch of my GitHub repo. It triggers nicely when I push a commit to master, and I'm very happy about it.

我还希望有一个 Jenkins 作业可以在此存储库中构建任何其他分支.IE.每当我将提交推送到一个分支(不是 master)时，我都希望有这个 Jenkins 工作来构建那个分支，并且只构建那个分支.

I would also like to have a single Jenkins job that would build any other branch in this repository. I.e. whenever I push a commit to a branch (that is not master), I'd like to have this Jenkins job to build that branch, and only that branch.

使用 GitHub pull-request 插件需要我创建一个 pull-request，并将我的提交与 master 合并.我想这样做而不必创建拉取请求，并且只构建我的提交而不将它与 master 合并.

Using the GitHub pull-request plugin requires me to create a pull-request, and merges my commit with master. I'd like to do this without having to create a pull-request, and to only build my commit without merging it with master.

设置 Git 插件来构建所有分支意味着每当我推送到 master 时，都会构建所有分支.我只想构建一个修改过的分支.

Setting up the Git plugin to build all branches means that whenever I push to master, all branches are built. I'd like to only build the one branch that has been modified.

这可以在詹金斯做吗?

推荐答案

我遇到了同样的问题，所以我建立了一个虚拟项目进行实验并找到了解决方案.并且发现是的，您可以只构建被推入的分支.

I was having the same issue so I set up a dummy project to experiment and found the solution. And found that yes, you can build only the branch that's been pushed into.

简短的回答是使用分支说明符".例如origin/feature**.

The short answer is to use a "Branch Specifier". For instance origin/feature**.

如果您使用 GitFlow 和您所有的功能分支以 feature/ 前缀命名，这就是解决方案.

If you're using the GitFlow and all your feature branches are named with a feature/ prefix, then this is the solution.

如果你好奇，这就是我是怎么想出来的.

And if you're curious here's how I figured it out.

从存储库的设置中，我使用 Jenkins 钩子 https://<jenkin server>/github-webhook/ 设置了服务 Github 插件".请注意，至少对我而言，在按下 "test" 后，由于某种原因，正在发送的有效载荷的消息从未改变以确认它已被接收/确认或任何东西.也许没有回复.这很令人困惑，但无论如何......

From the repository's settings I set the service "Github plugin" with the Jenkins hook https://<jenkin server>/github-webhook/. Note that, at least for me what happened was that for some reason after pressing "test", the message of the payload being sent never changed to confirm it was received/acknowledged or anything. Maybe there’s no reply. It's confusing, but anyway...

我创建了一个新的 Jenkins 作业并将 branch specifier 设置为 blank - 然后 Jenkins 自动设置**.

I created a new Jenkins job and set the branch specifier to blank -which Jenkins then automatically sets to **.

我创建了一个功能分支 feature/foo 并推送到其中.

I created a feature branch feature/foo and pushed into it.

• Build 1 被触发，但在 master 分支上.
• Build 2 也在 feature/foo 分支上被触发.

• Build 1 was fired, but on the master branch.
• Build 2 was also fired on the feature/foo branch.

因此，当使用 ** 或空白说明符时，插件将在 repo 的所有分支上触发构建，只要有对 任何 的推送.

So it seems with the ** or blank specifier the plugin will fire builds on all branches of a repo whenever there’s a push to any of them.

然后我尝试使用模式 refs/heads/feature/foo 并将另一个更改推送到 feature/foo 分支.

Then I tried with pattern refs/heads/feature/foo and pushed another change to the feature/foo branch.

• Build 3 在 feature/foo 分支上被触发.
• 没有触发其他构建.

还可以，但这太死板了.这将迫使我们为每个功能分支进行一项构建工作.我想要一份针对所有功能分支的构建工作.

Sort of ok, but this is too rigid. It would force us to have one build job for each feature branch. I wanted one build job for all feature branches.

然后我尝试了一个带有模式 refs/heads/feature** 的通配符并将更改推送到 feature/foo.

Then I tried a wildcard with pattern refs/heads/feature** and pushed changes to feature/foo.

• 未触发任何构建.

然后我尝试了分支说明符 refs/heads/feature/** 并推送.

Then I tried branch specifier refs/heads/feature/** and pushed.

• 没有触发构建

然后我看到了 Branch Specifier" 字段在通配符"部分下的帮助:

Then I saw the help of the "Branch Specifier" field reads this under the "Wildcards" section:

语法格式为:REPOSITORYNAME/BRANCH.另外，BRANCH被识别为*/BRANCH的简写，*被识别为通配符，** 被识别为包含分隔符 / 的通配符.因此，origin/branches* 将匹配 origin/branches-foo 但不匹配 origin/branches/foo，而 origin/branches** 将匹配 origin/branches-foo 和 origin/branches/foo.

The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, * is recognized as a wildcard, and ** is recognized as wildcard that includes the separator /. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.

所以我尝试了origin/feature**

• Build 4 是在 origin/feature/foo 上触发的.

• Build 4 was fired on origin/feature/foo.

尤里卡！似乎您不能在引用中使用通配符(以 refs/ 开头)，但是您可以使用实际分支的名称(以 origin/<开头)/code>).

Eureka! Seems you can’t use wildcards with the references (starting with refs/), but you can with the names of the actual branches (starting with origin/).

然后我创建了分支 feature/bar 并推送到它.验证只构建这个分支而不构建其他分支也以 feature/ 开头.

Then I created branch feature/bar and pushed to it. To verify that only this one would be built and not other branches also starting with feature/.

• Build 5 是在 origin/feature/bar 上触发的.

• Build 5 was fired on origin/feature/bar.

看起来差不多了.只需要再做几次测试.

Looked almost there. Just needed a few more tests.

然后我将另一个更改推送到 origin/master

Then I pushed another change to origin/master

• 未触发任何构建.太棒了！

然后我将另一个更改推送到 feature/bar，以测试仅会构建此分支.尽管 origin/master 也被推入了.

Then I pushed another change to feature/bar, to test that only this branch would be built. Despite the fact that origin/master had also been pushed into.

• Build 6 在 feature/bar 上被触发.
• 没有触发其他构建.

我觉得不错.

这篇关于只构建已经推送到的 Git 分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！