Revisión de código en Gitlab CE: se non hai aprobacións de solicitude de combinación, pero realmente quero facelo

Unha das funcións máis necesarias, que non está na versión gratuíta de GitLab, é a posibilidade de votar en contra da anulación do repositorio e controlar a solicitude de combinación (MR) mediante a revisión de código obrigatoria.

Fagamos nós mesmos a funcionalidade mínima: prohibiremos Merge ata que varios desenvolvedores dean o visto bo a MR.

Por que isto é necesario?

A nosa organización pode pagar facilmente unha licenza de GitLab. Pero, dado que o desenvolvemento realízase nun ciclo pechado sen acceso a Internet, e hai unha planificación orzamentaria estrita, a compra de licenzas autoxestionadas coa funcionalidade necesaria pode prolongarse durante moitos meses, pero hai que traballar agora.

Como resultado, tes que:

• ou prohibir completamente Merge en ramas protexidas para algúns desenvolvedores, pero entón os desenvolvedores que teñen dereito a Merge reciben conflitos ao combinar MR doutras persoas como bonificación;
• ou dálle a oportunidade de realizar fusións incontroladas coa súa rama mestra sen revisión de código, aínda que sexa Junior, quen foi contratado onte mesmo.

O primeiro que fixen foi Google, crendo que definitivamente alguén xa fixera algo semellante (sen modificar o código), pero resultou que aínda non había esa implementación na versión comunitaria.

Réxime xeral de traballo

Como exemplo, configuremos as aprobacións das solicitudes de combinación nun repositorio de proba a miña aplicación:

1. Imos crear un token de acceso á API de GitLab (a través del recibiremos información sobre o número de votos "a favor" e "en contra")
2. Imos engadir o token ás variables de GitLab
3. Desactivemos Combinar en caso de erros na canalización (se non hai suficientes votos positivos)
4. Configuramos a verificación de votos como parte do pipeline CI/CD
5. Prohibimos facer compromisos en sucursais protexidas; todos os cambios realízanse só a través de MR
6. Imos comprobar o que pasou ao final

1. Crea un token para acceder á API

Vaia a Configuración do usuario → Fichas de acceso e anote o token:

Conta para recibir un token
O acceso á API permíteche facer case calquera cousa cos teus repositorios, polo que recomendo crear unha conta Gitlab separada, dándolle dereitos mínimos sobre os teus repositorios (por exemplo, Reporter) e conseguir un token para esa conta.

2. Engade o token ás variables de Gitlab

Por exemplo, no paso anterior recibimos un token QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Abra Configuración → CI/CD → Variables → Engadir variable → GITLAB_TOKEN_FOR_CI

Como resultado obtemos:

Isto pódese facer nun repositorio ou nun grupo de depósitos.

3. Prohibimos Merge se non se recibe a aprobación dos compañeiros despois da revisión do código.

No noso caso, a prohibición de Fusionar será que a canalización de montaxe devolva un erro se non hai votos suficientes.

Vaia a Configuración → Xeral → Solicitudes de combinación → Comprobacións de combinación e active a opción As liñas de montaxe deben completarse correctamente.

4. Montaxe da canalización

Se aínda non creou unha canalización CI/CD para a súa aplicación
Crea un ficheiro na raíz do repositorio .gitlab-ci.yml co contido máis sinxelo:

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"

Repositorio separado para a configuración de CI/CD
Recomendaría facer un repositorio separado no que necesites crear un ficheiro myapp.gitlab-ci.yml para configurar a canalización. Deste xeito, pode controlar mellor o acceso dos participantes que poden cambiar a canalización de compilación e recibir un token de acceso.

Deberá especificarse a localización do novo ficheiro de canalización indo ao repositorio de myapp - Configuración - CI/CD - Liñas de montaxe - Ruta de configuración de CI personalizada - especifique o novo ficheiro, p. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Consello: use un linter para facer cambios nos ficheiros CI de GitLab
Aínda que traballes só, traballar a través de MR será unha boa axuda, xa que executar todos os cambios nos ficheiros de canalización a través dun linter. Se cometes un erro na sintaxe do ficheiro YAML, non romperá a túa produción, senón que simplemente bloqueará Merge.

Un exemplo de recipientes con linters que podes incorporar á túa canalización:

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

E un exemplo da fase de verificación:

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 por engadir algúns parámetros á túa canalización para que funcione:

stages:
- test

variables:
NEED_VOTES: 1

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

A variable NEED_VOTES determina cantos "pulgares cara arriba" debe ter MR para que Merge estea dispoñible. Un valor igual a un significa que vostede mesmo pode aprobar o seu MR dándolle "gústame".

include inclúe a fase de proba, que verifica o número de "gústame".

A canalización máis sinxela usando o exemplo de 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

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


Máis información sobre o que ocorre durante a verificación:

• existe unha restrición de que a comprobación só se fará ao crear MR nas ramas mestra ou release/*
• usando a API de GitLab, obtemos o número de "gústame" e "non me gusta"
• Calcula a diferenza entre respostas positivas e negativas
• se a diferenza é menor que o valor que establecemos en NEED_VOTES, bloqueamos a posibilidade de fusionar

5. Prohibir compromisos en ramas protexidas

Definimos as ramas para as que debemos realizar revisións de código e indicamos que só se pode traballar con elas a través de MR.

Para facelo, vai a Configuración → Repositorio → Ramas protexidas:

6. Comproba

Definir NEED_VOTES: 0

Facemos un MR e poñemos un "non me gusta".

Nos rexistros de compilación:

Agora pon "gústame" e comeza a comprobar de novo:

Fonte: www.habr.com