Gitlab CI 有一个称为“自动取消冗余管道”的功能。它非常有用 - 如果您将新的提交推送到 MR,它将取消该 MR 上任何正在运行的管道。这永远是你想要的。 不幸的是,它不仅仅适用于 MR,它似乎还会自动取消由提交到
master
触发的 CI 作业。这绝对不是您想要的。例如,如果您的 CI 相对较慢而您的提交率很高,那么您将永远不会完成
master
CI 作业 - 它们会不断被取消!
您可以将interruptible
标志应用于管道作业,以防止整个管道被取消。一旦设置了此标志的作业运行,那么任何阶段都不会运行。我们目前这样使用它:
default:
interruptible: true
make_uninterruptible:
stage: .pre
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
interruptible: false
script:
- echo "$CI_COMMIT_BRANCH is uninterruptible"
即一项尽快运行的作业,但前提是我们处于 master
。
这
几乎有效。问题是这样的:
尚未开始的作业始终被认为是可中断的:true,无论作业的配置如何。仅在作业开始后才考虑可中断配置。
有时,作业会稍微延迟,整个管道在有机会运行之前就被取消。
make_uninterruptible
这个问题有什么解决办法吗?
尚未开始的作业始终被认为是可中断的:true,无论作业的配置如何
目前,要使用GitLab 16.9
(2024 年 2 月)应该解决这个问题:
自动取消冗余流水线功能,必须将可取消的作业设置为
interruptible: true
来确定是否可以取消流水线。但这仅适用于当 GitLab 尝试取消管道时正在主动运行的作业。任何尚未开始的作业(处于“待处理”状态)也被认为可以安全取消,无论其interruptible
配置如何。缺乏灵活性会阻碍用户更好地控制自动取消管道功能可以取消哪些确切作业。为了解决这一限制,我们很高兴地宣布推出关键字,对作业取消进行更精细的控制。如果旧行为不适合您,您现在可以选择将管道配置为仅取消使用auto_cancel:on_new_commit
interruptible: true
显式设置的作业,即使它们尚未开始。您还可以将作业设置为永不自动取消。
问题