我在使用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文件的触发器解决了这个问题,但如果可能的话,我希望避免这种情况。
1条答案
按热度按时间3wabscal1#
为什么使用Gitlab resource_groups的作业在准备就绪时无法启动?
因为当您使用“最新的优先”处理模式时,它将从即将到来的作业列表中选择状态为
created
、scheduled
或waiting_for_resource
的第一个作业。我做错什么了吗?
我不认为你做错了什么,我认为这是进程模式的预期行为。
有人有类似的问题吗?
我在Gitlab的问题追踪器上看到了一个描述这个问题的issue,我完全同意这个问题的作者的这句话:
包含
created
的行为似乎将resource_group
的定义更改为锁以外的一点,因为这些作业并没有主动争用锁,但仍然阻止其他作业获得锁。因此,因为资源将选择
created
作业,所以进程模式不仅阻止并发运行,而且还阻止旧作业运行(如果新作业已经是created
(甚至不一定还在运行))。