為什么使用 gitlab resource_groups 的作業准備就緒后無法啟動？

Question

我在使用 gitlab 資源組進行管道設計時遇到問題。 在這里查看我簡單的 reduced.gitlab-ci.yml：

stages:
  - pre-build
  - build
  - test


pre-build:
  stage: pre-build
  script:
    - echo "Pre build"
    - sleep 5

build:
  stage: build
  needs: [pre-build]
  script:
    - sleep 100

test:
  stage: test
  needs: [pre-build, build]
  script:
    - echo "Test on hardware"
    - sleep 40
  resource_group: test-resource

我想要實現的目標：

• 測試硬件無法並行處理多個進程，所以我想在此硬件上一次只運行一個管道
• 我在最后階段使用資源組來實現這一點
• 想法：測試需要很多時間，例如，如果在測試期間進行了多次提交，我想在硬件測試完成后測試最新的一次。

我面臨的問題：讓我們使用上面 gitlab 文件中的示例。 如果您執行提交“A”，管道將開始運行並在應用程序之后到達測試作業。 105 秒。 問題是：如果您在這 105 秒內執行另一個提交“B”，則會發生一些有趣的事情：當“A”准備開始其測試工作時，它不會這樣做，因為提交“B”已經創建了一個較新的工作，即拉取資源組。

在我們真正的開發管道中，構建需要應用程序。 1.5小時。 這意味着，如果在此期間進行了另一次提交（很有可能），我們永遠不會進入測試作業/測試階段。

有沒有人有類似的問題，或者我做錯了什么？ 我們通過實現下游 gitlab yaml 文件的觸發器解決了這個問題，但我想盡可能避免這種情況。

Answer 1

為什么使用 Gitlab resource_groups 的作業准備就緒后無法啟動？

因為當您使用“最新優先”流程模式時，它將從即將到來的作業列表中選擇第一個作業，狀態為created 、 scheduled或waiting_for_resource 。

難道我做錯了什么？

我不認為你做錯了什么。 不幸的是，我認為這是流程模式的預期行為。

有沒有人有類似的問題？

我看到 Gitlab 問題跟蹤器上有一個問題描述了這個問題。 我完全同意問題作者的這句話：

包含created的行為似乎改變了resource_group的定義，超出了鎖的范圍，因為這些作業並未積極爭用鎖，但仍在阻止其他作業獲取它。

因此，因為資源將 select created作業，進程模式不僅阻止並發運行，而且如果created了新作業（甚至不一定正在運行），還會阻止舊作業運行。