不需要使用脚本控制台或其他插件，您可以通过在浏览器中的构建URL后输入/stop、/term或/kill来简单地中止构建。

从上述链接逐字引用:

管道作业可以通过向URL发送HTTP POST请求来停止 构建的端点。 <BUILD ID URL>/stop -中止管道。 <BUILD ID URL>/term -强制终止构建(应该只在stop不起作用时使用。 <BUILD ID URL>/kill -硬杀死一个管道。这是阻止管道的最具破坏性的方法，只能作为最后一种方法 度假胜地。

这对我来说每次都很有效:

Thread.getAllStackTraces().keySet().each() {
    if (it.name.contains('YOUR JOBNAME')) {  
      println "Stopping $it.name"
      it.stop()
    }
}

感谢funql.org

上面的答案对我来说几乎是可行的，但我有一个主要问题:由于Jenkins重启的时间特别糟糕，我有非常多的僵尸作业(大约100个)，所以手动查找每个僵尸作业的作业名称和构建号，然后手动杀死它们是不可可行的。以下是我如何自动找到并杀死僵尸工作的方法:

Jenkins.instance.getItemByFullName(multibranchPipelineProjectName).getItems().each { repository->
  repository.getItems().each { branch->
    branch.builds.each { build->
      if (build.getResult().equals(null)) {
        build.doKill()
      }
    }
  }
}

该脚本遍历所有作业的所有构建，并使用getResult().equals(null)来确定作业是否已经完成。在队列中但尚未开始的构建将不会被迭代(因为该构建不会在job.builds中)，并且已经完成的构建对于build. getresult()将返回非null的值。合法运行的作业的构建结果也会为null，因此在运行此作业之前，请确保没有不想终止的正在运行的作业。

在Multibranch Pipeline项目中，多个嵌套循环主要用于发现每个存储库的每个分支/PR;如果你没有使用Multibranch pipeline，你可以直接使用Jenkins.instance.getItems().each这样的东西来循环所有的作业。

我使用监控插件来完成这项任务。安装插件后

转到管理Jenkins >监控Hudson/Jenkins master 展开线程的细节，即右边的蓝色小链接 搜索挂起的作业名称 线程的名称将像这样开始 master的Executor #2:执行<your-job-name> #<build-number> 单击所需工作所在行的表格中最右边的红色圆形按钮

我看了Jenkins源代码，似乎我要做的是不可能的，因为停止一个作业似乎是通过线程中断完成的。我不知道为什么这个工作被搁置了。

编辑:

就业势不可挡的可能原因:

如果Jenkins陷入了无限循环，它就永远不能中止。 如果Jenkins在Java虚拟机中进行网络或文件I/O(例如长时间的文件复制或SVN更新)，则不能中止。

最近我遇到了一个节点/代理，它的一个执行程序被管道作业的构建“X”占用了几天，尽管该作业页面声称构建“X”不再存在(在后续10个构建后被丢弃(!)，正如管道作业中配置的那样)。在磁盘上验证:构建“X”真的消失了。

解决方案:代理/节点错误地报告了被占用的执行程序正在忙着运行构建“X”。中断该执行程序的线程会立即释放它。

def executor = Jenkins.instance.getNode('NODENAME').computer.executors.find {
    it.isBusy() && it.name.contains('JOBNAME')
}

println executor?.name
if (executor?.isBusy()) executor.interrupt()

考虑的其他答案:

来自@cheffe的答案:没有工作(见下一点，并在下面更新)。 thread. getallstacktraces()的答案:没有匹配的线程。 来自@levente-holló的答案和getBuildByNumber()的所有答案:不适用，因为构建已经不存在了! 来自@austinfromboston的答案:这接近于我的需求，但它也会破坏目前正在运行的任何其他构建。

更新: 我再次经历了类似的情况，Executor被一个(仍然存在的)已完成的管道构建占用了数天。这个代码片段是唯一可行的解决方案。