Question

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

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

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

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

我使用Git参数插件进行Branch-Selection并将其传递给Git分支refs。默认值为空字符串。

不幸的是，整个设置打破了Gitblit的推钩。虽然Jenkins仍然报告触发了具体项目来检查SCM，但只有在上次手动构建选择的分支中，才会启动构建。

检查Git轮询日志我看到只检查了先前选择的分支的更改。

根据我对所有这些的基本理解，我猜，SCM轮询触发器使用最后一个＆＃34;已知＆＃34; value，而不是参数的defaultValue。这是Jenkins，插件或我的配置中的错误。有没有其他人完成这样的双用途管道？

修改：我试过＆＃34; **＆＃34;作为默认值，相同的结果。

Answer 1

我找到了一个不太干净的问题解决方案。我添加了更多的构建工作，除了坐在SCM上并随后触发真实项目之外什么都不做。它们将“构建”的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更改了正确分支中的触发器构建并使用了管道。

虽然有效，但感觉有点hacky，所以如果你有更好的解决方案，请告诉我。

为什么Jenkins Git插件在被SCM工具

1 个答案: