Gitlab CE でのコード レビュー: マージ リクエストの承認がないが、本当に承認したい場合

GitLab の無料版にはない最も必要な機能の XNUMX つは、必須のコード レビューを使用してマージ リクエスト (MR) を制御するためにリポジトリをゼロにすることに反対する機能です。

最小限の機能は自分たちで実行します。数人の開発者が MR に「賛成」を与えるまで、Merge を無効にします。

そもそもなぜそうなるのでしょうか？

私たちの組織には GitLab ライセンスを購入する余裕があります。 ただし、開発はインターネットにアクセスせずにクローズド ループで実行され、厳密な予算計画があるため、必要な機能を備えた自己管理ライセンスの購入には何か月もかかる場合があり、今すぐ作業する必要があります。

その結果、次のことを行う必要があります。

• または、一部の開発者に対して保護されたブランチへのマージを完全に禁止しますが、マージの権利を持つ開発者は、ボーナスとして他の人の MR をマージすると競合が発生します。
• あるいは、昨日慣れてきたばかりのジュニアであっても、コードレビューなしでマスターブランチとの無制限のマージを実行できるようにします。

私が最初にやったことは、誰かがすでに同じようなことを（コードを修正せずに）行っていると信じてグーグルに行くことでした。しかし、コミュニティバージョンにはそのような実装がまだないことが判明しました。

一般的な作業計画

例として、テスト リポジトリでマージ リクエストの承認を設定してみましょう マイアプリ:

1. GitLab API にアクセスするためのトークンを作成しましょう (それを通じて、賛成票と反対票の数に関する情報を受け取ります)
2. GitLab 変数にトークンを追加する
3. パイプラインにエラーがある場合 (十分な「賛成」投票がない場合) はマージを無効にします。
4. CI/CD パイプラインの一部として投票検証を設定する
5. 保護されたブランチへのコミットは禁止され、すべての変更は MR を通じてのみ行われます。
6. 最後に何が起こったのか確認してみましょう

1. APIにアクセスするためのトークンを作成する

[ユーザー設定] → [アクセス トークン] に移動し、トークンを書き留めます。

トークンを受け取るアカウント
API アクセスを使用すると、リポジトリに対してほぼすべての操作が可能になるため、別の Gitlab アカウントを作成し、リポジトリに対する最小限の権限 (Reporter など) を付与し、そのアカウントのトークンを取得することをお勧めします。

2. トークンを Gitlab 変数に追加します

たとえば、前のステップでトークンを受け取りました。 QmN2Y0NOUFlfeXhvd21ZS01aQzgK

設定 → CI/CD → 変数 → 変数の追加 → を開きます。 GITLAB_TOKEN_FOR_CI

その結果、次のことが得られます。

これは、XNUMX つのリポジトリとリポジトリのグループの両方で実行できます。

3. コードレビュー後に同僚の承認が得られない場合、Merge を禁止します。

私たちの場合、Merge の禁止は、十分な投票がない場合にアセンブリ パイプラインがエラーを返すことになります。

[設定] → [一般] → [マージ リクエスト] → [マージ チェック] に移動し、[組立ラインが正常に実行される必要がある] オプションを有効にします。

4. パイプラインを設定する

アプリケーションの CI/CD パイプラインをまだ作成していない場合
リポジトリのルートにファイルを作成します .gitlab-ci.yml 簡単な内容:

stages:
  - build
  - test

variables:
  NEED_VOTES: 1

include:
  - remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
  stage: build
  script: echo "Hello world"

CI/CD 構成用の別のリポジトリ
パイプラインを設定するために myapp.gitlab-ci.yml ファイルを作成する必要がある別のリポジトリを作成することをお勧めします。 こうすることで、ビルド パイプラインを変更してアクセス トークンを取得できる共同作成者のアクセスをより適切に制御できます。

新しいパイプライン ファイルの場所は、myapp リポジトリ - 設定 - CI / CD - アセンブリ ライン - カスタム CI 構成パスに移動して指定する必要があります。たとえば、新しいファイルを指定します。 myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

ヒント: リンターを使用して GitLab CI ファイルに変更を加える
一人で作業する場合でも、MR を介して作業すると、リンターを介してパイプライン ファイルに対するすべての変更を実行できるため、優れたヘルパーとなります。 YAML ファイルの構文に誤りがある場合、動作中のパイプラインを中断することはできませんが、Merge がブロックされるだけです。

パイプラインに埋め込むことができるリンターを含むコンテナーの例:

Hub.docker.com/r/gableroux/gitlab-ci-lint
Hub.docker.com/r/sebiwi/gitlab-ci-validate

検証段階の例:

stages:
  - lint

lint:
  stage: lint
  image: sebiwi/gitlab-ci-validate:1.3.0
  variables:
    GITLAB_HOST: https://gitlab.com
  script:
    - CI_FILES=(./*.yml)
    - for f in "${CI_FILES[@]}"; do
        gitlab-ci-validate $f;
      done;

パイプラインを機能させるには、パイプラインにいくつかのパラメーターを追加する必要があります。

stages:
- test

variables:
NEED_VOTES: 1

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

NEED_VOTES 変数は、Merge を使用可能にするために MR が「賛成」の数を保持する必要があるかを決定します。 値が XNUMX の場合、あなた自身が自分の MR を「いいね！」することで承認できることを意味します。

include には、「いいね！」の数をチェックするテスト段階が含まれます。

myapp.gitlab-ci.yml を例として使用した最も単純なパイプライン
stages:
- build
- test

variables:
NEED_VOTES: 0

include:
- remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml"

run-myapp:
stage: build
image: openjdk
script:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java

check-approve.gitlab-ci.yml の内容
ci-mr:
stage: test
script:
- echo ${CI_API_V4_URL}
- echo "CI_PROJECT_ID ${CI_PROJECT_ID}"
- echo "CI_COMMIT_SHA ${CI_COMMIT_SHA}"
- "export MR_ID=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .id else {} end" | grep --invert-match {})"
- "export MR_TITLE=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .title else {} end" | grep --invert-match {})"
- "export MR_WIP=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .work_in_progress else {} end" | grep --invert-match {})"
- "export MR_UPVOTES=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .upvotes else {} end" | grep --invert-match {})"
- "export MR_DOWNVOTES=$(curl --silent --request GET --header "PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests | jq ".[] | if .sha == \"${CI_COMMIT_SHA}\" then .downvotes else {} end" | grep --invert-match {})"
- MR_VOTES=$(expr ${MR_UPVOTES} - ${MR_DOWNVOTES})
- NEED_VOTES_REAL=${NEED_VOTES:-1}
- echo "MR_ID ${MR_ID} MR_TITLE ${MR_TITLE} MR_WIP ${MR_WIP} MR_UPVOTES ${MR_UPVOTES} MR_DOWNVOTES ${MR_DOWNVOTES}"
- echo "MR_VOTES ${MR_VOTES} Up vote = 1, down vote = -1, MR OK if votes >=${NEED_VOTES_REAL}"
- if [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ];
then
echo "MR OK";
else
echo "MR ERROR Need more votes";
exit 1;
fi
image: laptevss/gitlab-api-util
rules:
- if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release/.*$/'


チェック時に何が起こるかについて詳しくは、以下をご覧ください。

• master または release /* ブランチで MR を作成する場合のみチェックが行われるという制限が設定されています
• GitLab APIを使用して、「いいね！」と「嫌い」の数を取得します。
• 肯定的な応答と否定的な応答の差を計算する
• 差が NEED_VOTES に設定した値より小さい場合、マージ機能がブロックされます。

5. 保護されたブランチへのコミットを無効にする

コードレビューを実施する必要があるブランチを決定し、それらのブランチは MR を通じてのみ処理できることを示します。

これを行うには、[設定] → [リポジトリ] → [保護されたブランチ] に移動します。

6. 確認

NEED_VOTESを設定: 0

MRをして「嫌い」を入れます。

ビルドログでは次のようになります。

ここで「いいね」を付けて再チェックを実行します。

出所： habr.com