好吧，我马上就消除最初的批评：我已经研究了这个问题，并尝试根据答复实施一个解决方案，非常有希望。然而，它没有飞起来。
我想做的是构建一个 CI 管道，开发团队可以通过 python 脚本自行决定触发该管道。这样，他们甚至可以设置一些耗时的测试来运行，而不会造成流程的严重中断。为此，我们目前只有一个管道，因为我们正在证明这个概念，但这个问题困扰着我。
运行脚本会添加一个构建作业（我们将该作业称为 job 0），再次运行它会向队列中添加另一个作业（作业 1）。但是，在 that 之后运行脚本不会执行任何操作。在执行作业 1 之前，不能再排队任何作业，并且无论出现什么情况，都只能有一个正在运行的作业和一个已排队的作业。
为了通过脚本实现触发作业，我使用这个插件，我的Python脚本最终要做的是形成一个具有以下一般形式的curl命令：
curl [url to jenkins]/job/[jenkins folder name]/job/[job name]/buildWithParameters?token=[some token]&user=[username]&branch=[branch that the job will pull] . . . &id=[some random uuid as hex string]
实际值与问题无关，被省略，省略号表示进一步省略的参数。
curl 本身做了它应该做的事情，因为它触发了一个工作。在运行完链接的问题后，我将 uuid 参数添加到curl中，并且每次运行脚本时都会生成它，因此在任何两次尝试运行它之间重复的可能性非常低。参数本身由为此设置的参数化作业接收，但该作业不会对此信息执行任何操作，它只是尝试绕过 Jenkins 不想使用相同参数来排队作业。
这里出了什么问题？我该如何解决这个问题？只能将一项作业排入队列会搞砸脚本的整个用例，因为它的计划是拥有一个简单、快速且易于使用的脚本，任何数量的开发人员都可以在闲暇时触发，触发次数不限。想要的。一种“按下按钮，继续编写代码，稍后通知测试结果”的形式。但是，如果只能将一项作业排队，即使是一小群开发人员也会使管道饱和，以至于新作业无法排队，他们必须自己在 Jenkins GUI 中启动该作业，这第一，会达不到目的。整个管道的第二个，将使访问和帐户管理变得绝对地狱。
非常感谢您在此事上的帮助。
最常见（也是最容易使用）的方法是每个开发人员在自己的分支中工作，并且 CI 作业是一个多分支管道，当这些开发人员的分支有拉取请求时，该管道将在这些开发人员的每次提交时触发。所以我不确定为什么需要通过Python脚本手动触发。但是，如果您尝试实现诸如 TeamCity 的个人构建之类的东西，我会理解。
因此，首先，如果您碰巧使用常用的（不是多分支）管道，那么这不是在 Jenkins 中设置 CI 的最佳方法 - 只需设置一个多分支管道，您就会看到差异。主要原因之一是 Jenkins 确实不会执行多个具有相同参数的管道作业。此后第二个将在工作历史中变得混乱。
除了评论中@MB建议的构建队列限制设置之外，还有其他一些可能限制并行构建数量的事情：