为什么 Jenkins Git 插件在被 SCM 工具触发时使用旧参数值

Question

在推送到多个 Git 存储库后，我们使用 Jenkins 构建服务器来构建我们的软件。

由于我们最近进行了一些代码重组，所以我尝试建立一个更复杂的构建管道，按照依赖项的顺序构建我们的每个产品（每个产品一个 Git 存储库）。

每个作业都会触发后续项目构建作业的执行，将 $GIT_BRANCH 传递给下一个作业。

整个管道运行良好，我在 origin/master 中开始构建第一个项目，项目 2、3 和 4 在 master 中构建。我从另一个分支开始，后续项目切换到这个分支。

我使用 Git 参数插件进行分支选择并将其传递给 Git 分支引用。默认值为空字符串。

不幸的是，整个设置破坏了 Gitblit 的推送挂钩。虽然 Jenkins 仍然报告具体项目已被触发以检查 SCM，但构建仅在提交位于为上次手动构建选择的分支中时才开始。

检查 Git 轮询日志，我发现仅检查了先前选择的分支是否有更改。

根据我对所有这些的基本理解，我猜想 SCM 轮询触发器使用最后一个 "known" 值，而不是参数的默认值。这是 Jenkins、插件或我的配置中的错误吗？有没有人完成过这样的两用管道？

编辑：我试过“**”作为默认值，结果相同。

Answer 1

我找到了一个不太干净的问题解决方案。我添加了进一步的构建作业，这些作业除了坐在 SCM 上什么都不做，然后触发真正的项目。他们将 "built" 的 GIT 提交 ID 传递给下一个作业。

这是一个例子：

projectA_trigger
    Freestyle Project
    GIT Repository configured
    Build triggert by SCM
    Post-Build-Action Trigger parameterized build of projectA, submit built GIT commit ID
projectA
    Maven-Project
    GIT repository configured
    Build NOT triggered by SCM
    Post-Build-Action Trigger parameterized build of projectB...

我为以前的每个主要项目创建了一个触发器项目，现在 SCM 更改触发器在正确的分支中构建并使用管道。

可行，但感觉有点老套，所以如果您有更好的解决方案，请告诉我。

为什么 Jenkins Git 插件在被 SCM 工具触发时使用旧参数值

Why is the Jenkins Git Plugin using old parameter values when being triggered by SCM tool

git

jenkins

jenkins-plugins