🥇Koda pārskats Gitlab CE: ja nav Merge request approvals, bet ļoti gribas

Viena no visnoderīgākajām funkcijām, kuras nav bezmaksas versijā GitLab, ir iespēja balsot pret glabātāja nolaišanu, kontrolējot Merge request (MR), izmantojot obligātu kodu pārskatu.

Izveidosim minimālo funkcionalitāti paši — aizliedīsim Merge, kamēr vairāki izstrādātāji neizteiks "pirkstu uz augšu" uz MR.

Kāpēc tas vispār ir nepieciešams?

Mūsu organizācija pilnīgi var atļauties iegādāties GitLab licenci. Bet, ņemot vērā, ka izstrāde notiek slēgtā kontūrā bez piekļuves internetam, un ir stingra budžeta plānošana, pašpārvaldīto variantu licenču iegāde ar nepieciešamo funkcionalitāti var ievilkties uz daudziem mēnešiem, bet darbam jāuzsākas jau tagad.

Tāpēc nākas:

vai pilnībā aizliegt Merge aizsargātajās zaros daļai izstrādātāju, taču tad izstrādātājiem, kuriem ir tiesības veikt Merge, rodas konflikti, apvienojot citu MR kā bonusu;
vai ļaut veikt nekontrolētus apvienojumus ar jūsu galveno zaru bez kodu pārskata, pat ja tas ir Junior, kurš darbu uzsāka tikai vakar.

Pirmajā iespējā devos uz Google, uzskatot, ka noteikti kāds jau ir izstrādājis kaut ko līdzīgu (bez koda uzlabojumiem), bet izrādījās, ka šādas realizācijas kopienas versijā vēl nebija.

Vispārējā darbības shēma

Kā piemēru pielāgosim Merge request apstiprinājumus uz testa glabātāju myapp:

Izveidosim tēriņu API piekļuvei GitLab (caur to iegūsim informāciju par balsu skaitu "par" un "pret")
Pievienosim tērēšanas piekļuvi GitLab mainīgajiem
Aizliegsim apvienot gadījumos, kad ir kļūdas ieplūdes procesā (ja balsu "par" ir nepietiekami)
Pielāgosim balsu pārbaudi kā daļu no CI/CD ieplūdes
Aizliegsim veikt izmaiņas aizsargātajos zaros, visus atjauninājumus veiksim tikai caur MR
Pārbaudīsim, kas beigās iznāca

1. Izveidojam tērēšanu API piekļuvei

Ieejiet Lietotāja iestatījumos → Pieejas tērēšana un uzrakstiet tērēšanas kodu:

Konta pārvaldība, lai saņemtu tērēšanu
Piekļuve API ļauj veikt gandrīz visu ar jūsu glabātājiem, tāpēc iesaku izveidot atsevišķu Gitlab kontu, piešķirt tam minimālās tiesības uz jūsu glabātājiem (piemēram, Reporter) un saņemt tērēšanu šim kontam.

2. Pievienojam tērēšanu GitLab mainīgajiem

Piemēram, iepriekšējā solī mēs ieguvām tērēšanu QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Atveriet Iestatījumus → CI/CD → Mainīgie → Pievienot mainīgo → GITLAB_TOKEN_FOR_CI

Beigās iegūsim:

To do this, you can use either a single repository or a group of repositories.

3. Set a restriction on Merge if colleague approvals are not obtained after the code review.

In our case, a restriction on Merge will be that the build pipeline returns an error if the number of votes is insufficient.

Go to Settings → General → Merge Requests → Merge Checks and enable the option 'Builds must succeed'.

4. Configure the pipeline

If you haven't set up a CI/CD pipeline for your application yet,
Create a file in the root of the repository .gitlab-ci.yml with the simplest content:

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"

Separate repository for CI/CD configuration
I would recommend creating a separate repository where you should create a file myapp.gitlab-ci.yml for pipeline configuration. This way, you will better control the access of participants who can modify the build pipeline and obtain an access token.

You will need to specify the location of the new pipeline file by going to the myapp repository — Settings — CI/CD — Pipelines — Custom CI configuration path — specify the new file, for example myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tip: Use a linter to make changes to GitLab CI files.
Even if you are working alone, using MR will be a good assistant, running all your pipeline file changes through a linter. If you make a syntax error in the YAML file, it won’t break your working pipeline, but will simply block the Merge.

Example containers with linters that you can integrate into your pipeline:

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

And an example of a check stage:

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;

You just need to add a few parameters to your pipeline to make everything work:

posmi: - tests

variables:
NEED_VOTES: 1

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

The NEED_VOTES variable determines how many "thumbs up" are required for the MR to be available for Merge. A value of one means you can approve your MR yourself by 'liking' it.

include connects the test stage, which checks the number of 'likes'.

Vienkāršākais pipelīns, izmantojot myapp.gitlab-ci.yml piemēru
posmi: - būvē - tests

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
scripts:
- echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- java HelloWorld.java

Saturu check-approve.gitlab-ci.yml
ci-mr: posms: tests scripts: - 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} Augšējā balsošana = 1, apakšējā balsošana = -1, MR OK ja balsis >= ${NEED_VOTES_REAL}" - ja [ "${MR_VOTES}" -ge "$(expr ${NEED_VOTES_REAL})" ]; then echo "MR OK"; else echo "MR KĻŪDA Nepieciešamas vairāk balsis"; exit 1; fi attēls: laptevss/gitlab-api-util noteikumi: - ja: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master" || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /(^release/.*$)/'

Vairāk par to, kas notiek pārbaudē:

ir noteikts ierobežojums, ka pārbaude notiks tikai tad, kad tiek izveidots MR uz master vai release/* filiālēm
izmantojot GitLab API, iegūstam «patīk» un «nepatīk» skaitu
aprēķinām atšķirību starp pozitīvām un negatīvām atbildēm
ja atšķirība ir mazāka par mūsu norādīto vērtību NEED_VOTES, tad bloķējam iespēju veikt apvienošanu