Revisió de codi a Gitlab CE: si no hi ha aprovacions de sol·licitud de fusió, però realment vull fer-ho

Una de les funcions més necessàries que no es troba a la versió gratuïta de GitLab és la possibilitat de votar en contra de posar a zero el dipòsit per controlar la sol·licitud de combinació (MR) mitjançant la revisió de codi obligatòria.

La funcionalitat mínima la farem nosaltres mateixos: desactivarem la fusió fins que diversos desenvolupadors donen un "polze amunt" a MR.

Per què és això?

La nostra organització es pot permetre el luxe de comprar una llicència de GitLab. Però, com que el desenvolupament es realitza en un bucle tancat sense accés a Internet i hi ha una planificació pressupostària estricta, la compra de llicències autogestionades amb la funcionalitat necessària pot trigar molts mesos i cal treballar ara.

Com a resultat, heu de:

• o prohibir completament la fusió en branques protegides per a alguns desenvolupadors, però els desenvolupadors que tenen dret a fusionar reben conflictes quan fusionen els MR d'altres persones com a bonificació;
• o permetre fer fusions incontrolades amb la seva branca mestra sense revisió de codi, encara que sigui un Junior que s'acaba d'instal·lar ahir.

El primer que vaig fer va ser anar a google, creient que algú ja havia fet alguna cosa semblant (sense refinar el codi), però va resultar que encara no hi havia aquesta implementació a la versió comunitària.

Esquema general de treball

Com a exemple, configurem les aprovacions de sol·licituds de combinació en un dipòsit de proves la meva aplicació:

1. Creem un testimoni per accedir a l'API de GitLab (a través d'ella rebrem informació sobre el nombre de vots a favor i en contra)
2. Afegiu un testimoni a les variables de GitLab
3. Desactiveu Fusionar si hi ha errors en el pipeline (si no hi ha prou vots "per").
4. Configureu la validació de vots com a part del pipeline CI/CD
5. Prohibirem fer compromisos amb sucursals protegides, només fem tots els canvis a través de MR
6. Comprovem què va passar al final

1. Creeu un testimoni per accedir a l'API

Aneu a Configuració d'usuari → Fitxa d'accés i anoteu el testimoni:

Compte per rebre el testimoni
L'accés a l'API us permet fer gairebé qualsevol cosa amb els vostres dipòsits, així que us suggereixo que creeu un compte de Gitlab independent, li doneu drets mínims als vostres dipòsits (com Reporter) i obtingueu un testimoni per a aquest compte.

2. Afegiu el testimoni a les variables de Gitlab

Per exemple, al pas anterior, vam rebre un testimoni QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Obriu Configuració → CI/CD → Variables → Afegeix una variable → GITLAB_TOKEN_FOR_CI

Com a resultat, obtenim:

Això es pot fer tant en un dipòsit com en un grup de dipòsits.

3. Prohibem la fusió si no es rep l'aprovació dels companys després de la revisió del codi

En el nostre cas, la prohibició de Merge serà que el pipeline de l'assemblea retorni un error si no hi ha prou vots.

Aneu a Configuració → General → Sol·licituds de combinació → Comprovacions de combinació i activeu l'opció Les línies de muntatge han de funcionar correctament.

4. Configureu la canonada

Si encara no heu creat un pipeline CI/CD per a la vostra aplicació
Creeu un fitxer a l'arrel del dipòsit .gitlab-ci.yml amb contingut senzill:

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"

Repositori separat per a la configuració de CI/CD
Recomanaria fer un repositori separat on hàgiu de crear un fitxer myapp.gitlab-ci.yml per configurar el pipeline. D'aquesta manera, podeu controlar millor l'accés dels col·laboradors que poden canviar el canal de compilació i obtenir un testimoni d'accés.

S'haurà d'especificar la ubicació del nou fitxer de canalització anant al repositori myapp - Configuració - CI / CD - Línies de muntatge - Camí de configuració de CI personalitzat - especifiqueu un fitxer nou, per exemple myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Consell: utilitzeu un linter per fer canvis als fitxers CI de GitLab
Fins i tot si treballeu sol, treballar amb MR serà un bon ajudant, executant tots els vostres canvis als fitxers de pipeline a través de linter. Si cometeu un error en la sintaxi del fitxer YAML, això no us permetrà trencar la canalització de treball, sinó que simplement bloquejarà Merge.

Un exemple de contenidors amb linters que podeu incrustar a la vostra canonada:

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

I un exemple de l'etapa de validació:

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;

Queda per afegir uns quants paràmetres al vostre pipeline perquè funcioni:

stages:
- test

variables:
NEED_VOTES: 1

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

La variable NEED_VOTES determina quants "polzes cap amunt" ha de tenir MR perquè la combinació estigui disponible. Un valor d'un significa que podeu aprovar el vostre MR fent-li "m'agrada".

inclou inclou la fase de prova, que comprova el nombre de "m'agrada".

La canalització més senzilla utilitza myapp.gitlab-ci.yml com a exemple
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

Contingut de 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/.*$/'


Obteniu més informació sobre què passa quan comproveu:

• s'estableix la restricció que la comprovació serà només quan es creï un MR a les branques mestres o de llançament /*
• utilitzant l'API de GitLab, obteniu el nombre de "m'agrada" i "no m'agrada"
• calcula la diferència entre respostes positives i negatives
• si la diferència és menor que el valor que vam establir a NEED_VOTES, bloquejarem la possibilitat de fusionar-nos

5. Desactivar els compromisos a les sucursals protegides

Determinem les branques per a les quals hem de fer una revisió de codi i indiquem que només es pot treballar amb MR.

Per fer-ho, aneu a Configuració → Repositori → Branques protegides:

6. Comprovació

Estableix NEED_VOTES: 0

Fem MR i posem un "no m'agrada".

Als registres de compilació:

Ara poseu "m'agrada" i torneu a comprovar:

Font: www.habr.com