为什么使用gitlab resource_groups的作业在准备就绪时无法启动?

46qrfjad  于 2023-02-02  发布在  Git
关注(0)|答案(1)|浏览(147)

我在使用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文件的触发器解决了这个问题,但如果可能的话,我希望避免这种情况。

3wabscal

3wabscal1#

为什么使用Gitlab resource_groups的作业在准备就绪时无法启动?
因为当您使用“最新的优先”处理模式时,它将从即将到来的作业列表中选择状态为createdscheduledwaiting_for_resource的第一个作业。
我做错什么了吗?
我不认为你做错了什么,我认为这是进程模式的预期行为。
有人有类似的问题吗?
我在Gitlab的问题追踪器上看到了一个描述这个问题的issue,我完全同意这个问题的作者的这句话:
包含created的行为似乎将resource_group的定义更改为锁以外的一点,因为这些作业并没有主动争用锁,但仍然阻止其他作业获得锁。
因此,因为资源将选择created作业,所以进程模式不仅阻止并发运行,而且还阻止旧作业运行(如果新作业已经是created(甚至不一定还在运行))。

相关问题