Gitlab CE의 코드 검토: 병합 요청 승인이 없지만 정말 하고 싶은 경우

GitLab 무료 버전에는 없는 가장 필요한 기능 중 하나는 필수 코드 검토를 사용하여 저장소 무효화에 반대하고 병합 요청(MR)을 제어하는 ​​기능입니다.

최소한의 기능은 스스로 해보자. 여러 개발자가 MR에 엄지손가락을 치켜세울 때까지 Merge를 금지할 것이다.

이것이 왜 필요한가요?

우리 조직은 GitLab 라이센스를 쉽게 구입할 여유가 있습니다. 그러나 개발은 인터넷 접속 없이 폐쇄 루프로 진행되고 엄격한 예산 계획이 있기 때문에 필요한 기능을 갖춘 자체 관리형 라이선스를 구매하는 데 수개월이 걸릴 수 있지만 지금 작업을 완료해야 합니다.

결과적으로 다음을 수행해야 합니다.

• 또는 일부 개발자의 경우 보호된 브랜치에서 병합을 완전히 금지하지만 병합 권한이 있는 개발자는 보너스로 다른 사람의 MR을 병합할 때 충돌을 받습니다.
• 또는 어제 고용된 주니어라도 코드 검토 없이 마스터 브랜치와 통제되지 않은 병합을 수행할 수 있는 기회를 제공할 수 있습니다.

내가 한 첫 번째 일은 누군가가 이미 비슷한 일을 (코드 수정 없이) 확실히 수행했다고 믿었지만 커뮤니티 버전에는 아직 그러한 구현이 없다는 것이 밝혀진 Google이었습니다.

일반적인 작업 계획

예를 들어 테스트 저장소에서 병합 요청 승인을 구성해 보겠습니다. 마이앱:

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

결과적으로 우리는 다음을 얻습니다:

이는 하나의 저장소 또는 저장소 그룹에서 수행할 수 있습니다.

3. 코드 검토 후 동료의 승인을 받지 못할 경우 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 파일의 구문에 실수가 있어도 프로덕션 파이프라인이 중단되지는 않지만 단순히 병합이 차단됩니다.

파이프라인에 구축할 수 있는 Linter가 포함된 컨테이너의 예:

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 변수는 병합을 사용할 수 있으려면 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