Jenkins 源代码管理 (GIT) 忽略 refspec/branch 过滤器
Jenkins Source Management (GIT) ignoring refspec/branch filters
我有两个主要的 jenkins 环境，它们使用相同的存储库但用于不同的版本。据我所知，这是一个常见的设计。产品具有 beta 和 release 状态，应通过相应的 jenkins 上的自动化管道进行相应部署。
这是 beta 版本的 GIT 配置示例：
分支：*/tags/beta/*
refspec: +refs/tags/beta/:refs/remotes/origin/tags/beta/
下面是 release 版本的 GIT 配置示例：
分支：*/tags/release/*
refspec: +refs/tags/release/:refs/remotes/origin/tags/release/
问题是，无论名称为 beta/v1.0.1 或 release/v1.1.0 的标签是否被推送到原点，jenkins 都会检测到更改并仅使用看似 latest 标签的内容进行重建, 忽略过滤。
现在我正在考虑这个问题，这可能是相关的。这是他们两个的构建触发器部分。存储库上的 webhook 设置为仅在标记推送时触发。我的期望是每个标签推送都发送到 jenkins，然后评估它是否与过滤器匹配，但显然不是这样。
我对 jenkins 还很陌生，所以我想我误解了它是如何工作的，如果你有时间的话，我希望得到一些指导和例子。
运行 标签推送以获取两个 jenkins 的日志示例：
测试版：
11:50:37 > git --version # 'git version 2.20.1'
11:50:37 using GIT_SSH to set credentials
11:50:37 > git fetch --tags --force --progress -- git@gitlab.com:[OMITTED].git +refs/tags/beta/*:refs/remotes/origin/tags/beta/* # timeout=10
11:50:38 > git rev-parse refs/tags/beta/v1.0.14^{commit} # timeout=10
11:50:38 > git branch -a -v --no-abbrev --contains 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:38 Checking out Revision 9befbfacfc2254de259203283705133834dcd62f (origin/tags/betav1.0.14, origin/tags/beta/v1.0.14)
11:50:38 > git config core.sparsecheckout # timeout=10
11:50:38 > git checkout -f 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:38 Commit message: "testing"
发布：
11:50:33 > git --version # 'git version 2.20.1'
11:50:33 using GIT_SSH to set credentials Gitlab SSH credentials
11:50:33 > git fetch --tags --force --progress -- git@gitlab.com:[OMITTED].git +refs/tags/*:refs/remotes/origin/tags/release/* # timeout=10
11:50:34 > git rev-parse refs/tags/beta/v1.0.14^{commit} # timeout=10
11:50:34 > git branch -a -v --no-abbrev --contains 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:34 Checking out Revision 9befbfacfc2254de259203283705133834dcd62f (origin/tags/beta/v1.0.14, origin/tags/release/beta/v1.0.14)
11:50:34 > git config core.sparsecheckout # timeout=10
11:50:34 > git checkout -f 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:34 Commit message: "testing"
詹金斯 v2.263.1
GIT插件版本如下：
GIT Client Plugin 3.6.0
GIT Parameter Plugin 0.9.13
GIT Plugin 4.5.2
如 this issue, and illustrated in this issue 中所建议，我将使用作为分支说明符：
:origin/tags/beta/*
# or
:origin/tags/release/*
这将迫使 Jenkins 考虑对 origin 的更改。
如OP Claudio in ，问题如：
- JENKINS-58907（“Wrong tag determined on commit with multiple tags”）建议 Jenkins（Git 插件）在按字母顺序排序后使用第一个标签，这是不准确的。
- JENKINS-64720（Git插件无法签出标签）更清楚：
The branch parameter of the git pipeline step does not accept a tag name.
Many other cases are also not supported with the git pipeline step as described in the online help. The checkout step is the preferred Pipeline step for full access to git.
我有两个主要的 jenkins 环境，它们使用相同的存储库但用于不同的版本。据我所知，这是一个常见的设计。产品具有 beta 和 release 状态，应通过相应的 jenkins 上的自动化管道进行相应部署。
这是 beta 版本的 GIT 配置示例：
分支：*/tags/beta/*
refspec: +refs/tags/beta/:refs/remotes/origin/tags/beta/
下面是 release 版本的 GIT 配置示例：
分支：*/tags/release/*
refspec: +refs/tags/release/:refs/remotes/origin/tags/release/
问题是，无论名称为 beta/v1.0.1 或 release/v1.1.0 的标签是否被推送到原点，jenkins 都会检测到更改并仅使用看似 latest 标签的内容进行重建, 忽略过滤。
现在我正在考虑这个问题，这可能是相关的。这是他们两个的构建触发器部分。存储库上的 webhook 设置为仅在标记推送时触发。我的期望是每个标签推送都发送到 jenkins，然后评估它是否与过滤器匹配，但显然不是这样。
我对 jenkins 还很陌生，所以我想我误解了它是如何工作的，如果你有时间的话，我希望得到一些指导和例子。
运行 标签推送以获取两个 jenkins 的日志示例：
测试版：
11:50:37 > git --version # 'git version 2.20.1'
11:50:37 using GIT_SSH to set credentials
11:50:37 > git fetch --tags --force --progress -- git@gitlab.com:[OMITTED].git +refs/tags/beta/*:refs/remotes/origin/tags/beta/* # timeout=10
11:50:38 > git rev-parse refs/tags/beta/v1.0.14^{commit} # timeout=10
11:50:38 > git branch -a -v --no-abbrev --contains 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:38 Checking out Revision 9befbfacfc2254de259203283705133834dcd62f (origin/tags/betav1.0.14, origin/tags/beta/v1.0.14)
11:50:38 > git config core.sparsecheckout # timeout=10
11:50:38 > git checkout -f 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:38 Commit message: "testing"
发布：
11:50:33 > git --version # 'git version 2.20.1'
11:50:33 using GIT_SSH to set credentials Gitlab SSH credentials
11:50:33 > git fetch --tags --force --progress -- git@gitlab.com:[OMITTED].git +refs/tags/*:refs/remotes/origin/tags/release/* # timeout=10
11:50:34 > git rev-parse refs/tags/beta/v1.0.14^{commit} # timeout=10
11:50:34 > git branch -a -v --no-abbrev --contains 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:34 Checking out Revision 9befbfacfc2254de259203283705133834dcd62f (origin/tags/beta/v1.0.14, origin/tags/release/beta/v1.0.14)
11:50:34 > git config core.sparsecheckout # timeout=10
11:50:34 > git checkout -f 9befbfacfc2254de259203283705133834dcd62f # timeout=10
11:50:34 Commit message: "testing"
詹金斯 v2.263.1
GIT插件版本如下：
GIT Client Plugin 3.6.0
GIT Parameter Plugin 0.9.13
GIT Plugin 4.5.2
如 this issue, and illustrated in this issue 中所建议，我将使用作为分支说明符：
:origin/tags/beta/*
# or
:origin/tags/release/*
这将迫使 Jenkins 考虑对 origin 的更改。
如OP Claudio in
- JENKINS-58907（“Wrong tag determined on commit with multiple tags”）建议 Jenkins（Git 插件）在按字母顺序排序后使用第一个标签，这是不准确的。
- JENKINS-64720（Git插件无法签出标签）更清楚：
The branch parameter of the git pipeline step does not accept a tag name.
Many other cases are also not supported with the git pipeline step as described in the online help. The checkout step is the preferred Pipeline step for full access to git.