有没有人可以帮助看看这种方法是否存在任何潜在的缺点
在我们的场景中，我们有多个项目经常被添加，我们希望尽量减少创建作业的工作量，因此我们考虑重复使用不同参数的作业。我们正在使用管道和参数化触发器插件来实现作业之间的这种依赖性。在我们的例子中，我们将启动，构建，测试和部署作业设置为管道。启动作业只是接受参数来触发下线作业，例如源代码位置和后续作业的公共工作空间。对于每个新项目，我们都会添加一个具有不同参数的新启动作业，并触发构建作业，这对于参数不同的所有项目都是通用的。
感谢是否有人可以提出我们可能会遇到的这种方法的潜在缺点。
提前致谢， 桑托什
答案 0 :(得分：0)
取决于您使用Jenkins报告/跟踪的数量。
例如，从不同的SCM位置（通过参数）获得相同的构建作业是完全正常的，但随着参数的变化，它将在之前的结账时检查并检查新的SCM地点。
另一个示例，具有相同的部署作业，具有不同的工件参数。我已经拥有了，并且远离了它。原因：当我被问到“最后一次构建部署到环境A时是什么时候？”我必须手动梳理每个构建历史记录以找到与参数“A”匹配的构建历史记录。甚至懒得试图向你团队中的其他人解释那个^。现在，我有一个“部署到环境A的工作”，“将工作部署到环境B”等等，并且跟踪部署历史很容易。
因此，如果您的Jenkins自主运行，并且没有人（包括您）登录到UI，那么无论如何都要使用单个作业。但是如果人们使用Jenkins来跟踪和审查控制台日志，那么拥有更细粒度的工作确实有帮助
巧合的是，如果您有更细粒度的工作，那么您将不会遇到此用户遇到的问题：Jenkins: Filter build history by label or parameter