パイプラインでは、Merge Requestsターゲットブランチが特定のブランチ(マスターまたはリリースなど)である場合にのみ、ジョブを実行したいと思います。
これは可能ですか?
私は https://docs.gitlab.com/ee/ci/variables/ を読みましたが、何かを見逃さない限り、何も助けになるものは見当たりません。
Gitlab CIは、マージリクエストを認識しません(現時点では)。パイプラインはOriginブランチで実行されるため、宛先を取得することはできません。
更新:2019-03-21
GitLabには、バージョン11.6以降のマージリクエスト情報の変数があります( https://docs.gitlab.com/ce/ci/variables/ 変数はCI_MERGE_REQUEST_
で始まります)。ただし、これらの変数はmerge request pipelines
でのみ使用可能です。( https://docs.gitlab.com/ce/ci /merge_request_pipelines/index.html )
マージリクエストのCIジョブを設定するには、マージリクエストのジョブにonly: merge_request
を設定する必要があります。そして、それらのジョブでCI_MERGE_REQUEST_*
変数を使用できます。
ここでの最大の落とし穴は、only: merge_request
が通常のonly/except
パラメーターとは完全に異なる動作をすることです。
通常のonly/except
パラメーター:( https://docs.gitlab.com/ce/ci/yaml/README.html#onlyexcept-basic )
only
は、ジョブを実行するブランチとタグの名前を定義します。except
は、ジョブが実行されないブランチとタグの名前を定義します。
only: merge_request
:( https://docs.gitlab.com/ce/ci/merge_request_pipelines/index.html#exexcept-certain-jobs )
only: merge_requests
パラメーターの動作では、そのパラメーターを持つジョブのみがマージ要求のコンテキストで実行されます。他のジョブは実行されません。
only: merge_request
がすべてのジョブに存在するため、ジョブを以前のように再編成するのは難しいと感じました。したがって、CIジョブでMR情報を取得するために、元の回答でワンライナーを使用しています。
元の答え:
番号。
ただし、GitLabには2019 Q2にこの機能の計画があります: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#final-assumptions
現在、回避策を使用してこれを実現できます。この方法は、Rekovniの答えが説明したとおりであり、実際に機能します。
シンプルなワンライナーがあり、MRのターゲットブランチを現在のブランチから取得します。
script: # in any script section of gitlab-ci.yml
- 'CI_TARGET_BRANCH_NAME=$(curl -LsS -H "PRIVATE-TOKEN: $AWESOME_GITLAB_API_TOKEN" "https://my.gitlab-instance.com/api/v4/projects/$CI_PROJECT_ID/merge_requests?source_branch=$CI_COMMIT_REF_NAME" | jq --raw-output ".[0].target_branch")'
説明:
CI_TARGET_BRANCH_NAME
は、解決されたターゲットブランチ名を格納する新しく定義された変数です。さまざまな使用法では、変数を定義する必要はありません。
AWESOME_GITLAB_API_TOKEN
は、リポジトリのCI/CD変数構成で構成された変数です。これは、api
スコープを持つGitLabパーソナルアクセストークン(ユーザー設定で作成)です。
curl
オプションについて:-L
は、curlにHTTPリダイレクトを認識させます。 -sS
はcurlサイレント(-s
)になりますが、show(-S
)エラーになります。 -H
は、GitLab APIにアクセスする権限情報を指定します。
使用されたAPIは https://docs.gitlab.com/ce/api/merge_requests.html#list-project-merge-requests にあります。 source_branch
属性を使用して、現在のMRパイプラインが実行されているかどうかを判断します。したがって、ソースブランチに異なるターゲットブランチへの複数のMRがある場合、|
の後の部分を変更し、独自のロジックを実行することができます。
jq
( https://stedolan.github.io/jq/ )については、JSONのもの(GitLab APIが返すもの)を処理するための単純なCLIユーティリティです。 node -p
または任意のメソッドを使用できます。
これがあなたが本当に望んでいるものである場合、 マージ要求API および CI変数 を使用してこれを達成できる非常に複雑な方法(テストされていない)があります。
ワークフロー/ビルドステップでは次のようになります。
feature/test
からmaster
へのマージ要求を作成しますCI_PROJECT_ID
変数を使用して現在のプロジェクトからすべてのオープンマージリクエストを取得し、source_branch
およびtarget_branch
でフィルタリングします。source_branch
およびtarget_branch
がそれぞれfeature/test
およびmaster
であるマージ要求が開いている場合は、ビルドを続行します。それ以外の場合は、ビルドの残りをスキップします。APIを使用する場合、CI_JOB_TOKEN
変数を使用して認証できるとは思わないため、おそらく独自の パーソナルアクセストークン を作成し、それを- CI変数 ビルドジョブで使用します。
お役に立てれば!
GitLab 11.6現在、 CI_MERGE_REQUEST_TARGET_BRANCH_NAME
。