是否可以跨多个gitlab管道“锁定”一组作业


11

我有多个工作使用单个外部资源(服务器)。第一项工作将应用程序部署到环境中,第二项在此环境中执行测试,第三项在此环境中执行集成测试。

我知道有资源组选项。但是它仅锁定作业。如果两条管道并行运行,我需要执行job1job2job3从第一管线,只有当第一管线释放的资源-第二个管道可以启动jobs1-3。有没有办法做到这一点?管道中还有其他工作-它们应该同时工作。

Answers:


1

设置作业1-3的专用转轮。

  1. 使用唯一标签(例如'jobs-1-2-3')设置新跑步者,并将选项设置concurrent1

  2. 在问题中添加唯一标签,例如“ jobs-1-2-3”。

    job1:
      tags:
        - jobs-1-2-3
    job2:
      tags:
        - jobs-1-2-3
    job3:
      tags:
        - jobs-1-2-3
    

恕我直言,这是更少的努力,更可靠。


不确定是否可以。可能的情况:管道1(p1)运行作业1(j1),然后管道2(p2)运行作业1(j1),然后管道1启动作业2。我需要p1运行j1,j2,j3,然后p2运行j1,j2,j3。看起来资源小组将做同样的事情
Zufar Muhamadeev

由于新跑步者一次只能处理一项任务,并且由于具有唯一标签,其他跑步者也不会接任这些任务,因此可以确保p2等待p1完成。另请参阅docs.gitlab.com/ee/user/project/pipelines/...
RiWe

我不想取消待处理的管道。正如我所说,还有其他工作-它们应该同时工作。那么,您是否在说两个管道正在运行并且设置了并发选项-运行程序将始终从第一个管道中选择作业?
Zufar Muhamadeev

是的,运行者将先处理p1中的作业,然后再处理p2中的作业。
RiWe

到目前为止,这种方法仍然有效
Zufar Muhamadeev

0

我认为可以通过needsresource_group关键字以及gitlab API 来实现。

每个作业都会以形式接收其所属的管道ID predefined-variable。如果使用gitlab api,则可以查看管道中其他作业的状态。如果您可以使用此状态needs以及resource_group关键字,我认为您可以实现预期的目标。有关更多详细信息,请参见以下代码的说明及其注释。

stages:
  - ready
  - build

job1:
  stage: build
  needs: [starting_signal]
  script: 
    - sleep 10 && echo "job1"
job2:
  stage: build
  needs: [starting_signal]
  script:
    - sleep 20 && echo "job2"
job3:
  stage: build
  needs: [starting_signal]
  script:
    - sleep 30 && echo "job3"

starting_signal:
  stage: ready
  script:
    - # TODO: You need to implement it using the GitLab API.
    - # The starting condition for "job1-3" is
    - # that this `starting_signal` job finished successfully.
    - # And the condition that ends with the success of this job
    - # is that `traffic_light` becomes running.

traffic_light: 
  stage: ready
  resource_group: traffic_light
  script:
    - # TODO: You need to implement it using the GitLab API.
    - # The end condition for `traffic_light` is
    - # the end of job1-3 execution.
    - # In other words, this job must be checked and waited
    - # through gitlab api until job 1,2,3 is finished.
    - # Since this job locks the execution of a `traffic_light` job
    - # in another pipeline, the `starting_signal` job in another 
    - # pipeline does not succeed.

(我没有亲自测试过,因此此方法需要进行审查。)

参考:


感谢您的回答。如果我理解traffic_light作业的正确性,则应该等待并发管道中作业1-3的执行完成。我不喜欢这种方法-您的ci分钟将浪费在检查并发管道的状态上。
Zufar Muhamadeev

如果您担心ci分钟,可以使用自托管的gitlab-runner来traffic_light使用tags关键字。如今,许多云供应商都提供免费层实例,这些实例足以运行诸如之类的简单等待作业traffic_light
aluc

看起来gitlab即使在自托管的跑步者身上也要花费数分钟。我正在尝试重试具有自托管跑步者标签的作业-但它不会启动并显示有关管道分钟数超出限制的消息:i.imgur.com/vBftxmk.png
Zufar Muhamadeev

1
如果与this(gitlab.com/gitlab-org/gitlab-foss/issues/58942)问题有关,则一旦超出配额,特定运行程序似乎将不起作用。我不确定是否很清楚,但这与您的原始问题没有直接关系,因此我建议在此处或在gitlab上发布单独的问题。
aluc
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.