複数のgitlabパイプライン間でジョブのグループを「ロック」することは可能ですか


11

単一の外部リソース(サーバー)を使用する複数のジョブがあります。最初のジョブはアプリを環境にデプロイし、2番目はこの環境でテストを実行し、3番目はこの環境で統合テストを実行します。

リソースグループオプションがあることは知っています。ただし、ロックされるのはジョブのみです。2つのパイプラインを同時に実行するjob1場合job2job3最初のパイプラインから、最初のパイプラインがリソースを解放したときにのみ、2番目のパイプラインを起動できるように実行する必要がありjobs1-3ます。これを達成する方法はありますか?パイプラインには他のジョブがあります-それらは同時に動作するはずです。

回答:


1

ジョブ専用のランナーをセットアップする1-3。

  1. 一意のタグ(「jobs-1-2-3」など)を使用して新しいランナーセットアップし、オプションconcurrentをに設定します1

  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 run j1、j2、j3が必要で、次にp2 run j1、j2、j3が必要です。リソースグループも同じように見える
Zufar Muhamadeev

新しいランナーは一度に1つのジョブのみを処理し、一意のタグにより他のランナーはジョブを選択しないため、p2が確実にp1が完了するまで待機します。docs.gitlab.com/ee/user/project/pipelines/…
RiWe

保留中のパイプラインをキャンセルしたくありません。私が言ったように他の仕事があります-それらは同時に働くべきです。それで、2つのパイプラインが実行されており、並行オプションが設定されている場合、実行していますか?ランナーは常に最初のパイプラインからジョブを選択しますか?
Zufar Muhamadeev

はい、ランナーはp2からのジョブを処理する前にp1のジョブを完了します。
RiWe

このアプローチはこれまでのところ機能します
Zufar Muhamadeev

0

私はそれを介して実装することができると思うneedsresource_group、キーワードとgitlabのAPI。

すべてのジョブは、それが属するパイプラインIDをとして受け取りpredefined-variableます。gitlab apiを使用すると、パイプライン内の他のジョブのステータスを確認できます。このステータスを使用していただければneedsresource_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分が気になる場合は、キーワードをtraffic_light使用するために自己ホスト型のgitlab-runnerを使用できますtags。現在、多くのクラウドベンダーが無料階層インスタンスを提供しています。これは、などの単純な待機ジョブを実行するのに十分traffic_lightです。
aluc

gitlabはセルフホストランナーでも数分を数えるようです。私は自己ホスト型ランナーのためのタグを持っているウィッヒ再試行ジョブにしようとしています-しかし、それは起動し、番組パイプライン分についてのメッセージ制限するものではないことは超えて:i.imgur.com/vBftxmk.png
Zufar Muhamadeev

1
これ(gitlab.com/gitlab-org/gitlab-foss/issues/58942)の問題に関連している場合、割り当てを超えると特定のランナーが機能しないようです。これが明確かどうかはわかりませんが、元の質問とは直接関係がないため、ここまたはgitlabで別の質問を投稿することをお勧めします。
aluc
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.