我们正在将我们的构建系统从哈德逊转移到Jenkins，并转移到SCM中的声明性管道。唉，看起来有一些打嗝。在哈德逊中，当一个作业被调度并在队列中等待时，该项目没有新的作业被调度，这是有道理的。然而，在Jenkins中，我观察到例如。作业的5个示例同时启动，由各种上游或SCM更改事件触发。它们都已经开始了，其中一个实际上正在构建节点上运行，其余的正在等待“等待下一个可用的执行器（构建节点）”。当构建节点变得可用时，它们都尽职尽责地依次开始运行，并且都尽职尽责地运行，其中大多数根本没有目的，因为没有更多的更改，这一切都需要大量的时间。
SCM中的声明性管道脚本以节点声明开始：
pipeline {
agent {
label 'BuildWin6'
}
...我猜实际的问题是Jenkins开始运行这些作业，即使指定的构建节点很忙碌。也许它认为我可能已经改变了SCM中的Jenkinsfile，并指定了另一个构建节点来运行它？无论如何，如何避免这种情况？这可能是显而易见的事情，因为谷歌没有发现任何类似的投诉。
2条答案
按热度按时间llew8vvj1#
为了记录，回答我自己。看起来最好的解决方案是定义另一个触发器作业，它由SCM更改触发。它不应该做任何其他的事情，只会检查出所需的svn repos（使用depthOption：“空”表示空间和速度）。需要将作业绑定为在与主作业相同的代理上运行。
主作业仅由第一个作业触发，而不是由SCM更改触发。现在，如果主任务构建了一个小时，并且在这段时间内有10个svn提交，Jenkins会安排10个触发任务构建运行.由于座席忙碌，他们都在排队等候。当代理变得可用时，它们都会快速运行并触发主作业。主作业只触发一次，因为主作业必须确保其宽限/安静期大于触发作业的运行时间。
qgelzfjb2#
我们的解决方案是让第一步检查触发器文件，然后在没有找到时创建它并执行主任务，否则就放弃。然后，流程中的最后一步将删除触发器文件。
这里的额外好处是，如果流中途失败，则在没有干预的情况下不能重新启动（即，移除文件或设置Jenkins参数，该Jenkins参数路由管线以忽略该文件），这意味着有人确认该失败。