Codeüberprüfung in Gitlab CE: Wenn es keine Genehmigungen für Merge-Anfragen gibt, ich es aber wirklich möchte

Eine der am meisten benötigten Funktionen, die nicht in der kostenlosen Version von GitLab enthalten ist, ist die Möglichkeit, gegen das Nullen des Repositorys zu stimmen, um die Merge-Anfrage (MR) mithilfe der obligatorischen Codeüberprüfung zu steuern.

Wir werden die Mindestfunktionalität selbst übernehmen – wir werden Merge deaktivieren, bis mehrere Entwickler MR ein „Daumen hoch“ geben.

Warum ist das überhaupt so?

Unsere Organisation kann es sich leisten, eine GitLab-Lizenz zu kaufen. Da die Entwicklung jedoch in einem geschlossenen Kreislauf ohne Zugang zum Internet erfolgt und eine strenge Budgetplanung vorliegt, kann der Kauf selbstverwalteter Lizenzen mit der erforderlichen Funktionalität viele Monate dauern und Sie müssen jetzt daran arbeiten.

Daher müssen Sie Folgendes tun:

• oder das Zusammenführen in geschützte Zweige für einige Entwickler vollständig verbieten, aber dann erhalten Entwickler, die das Recht zum Zusammenführen haben, als Bonus Konflikte, wenn sie die MRs anderer Leute zusammenführen;
• Oder Sie können unkontrollierte Zusammenführungen mit Ihrem Hauptzweig ohne Codeüberprüfung durchführen, selbst wenn es sich um einen Junior handelt, der sich erst gestern eingelebt hat.

Als erstes ging ich zu Google und glaubte, dass jemand bereits etwas Ähnliches getan hatte (ohne den Code zu verfeinern), aber es stellte sich heraus, dass es in der Community-Version noch keine solche Implementierung gab.

Allgemeines Arbeitsschema

Als Beispiel richten wir Genehmigungen für Zusammenführungsanforderungen in einem Test-Repository ein meine App:

1. Erstellen wir ein Token für den Zugriff auf die GitLab-API (über dieses erhalten wir Informationen über die Anzahl der Ja- und Nein-Stimmen).
2. Fügen Sie GitLab-Variablen ein Token hinzu
3. Deaktivieren Sie die Zusammenführung, wenn Fehler in der Pipeline vorliegen (wenn nicht genügend „Ja“-Stimmen vorhanden sind).
4. Richten Sie die Abstimmungsvalidierung als Teil der CI/CD-Pipeline ein
5. Wir verbieten die Durchführung von Commits für geschützte Zweige und nehmen alle Änderungen nur über MR vor
6. Schauen wir uns an, was am Ende passiert ist

1. Erstellen Sie ein Token, um auf die API zuzugreifen

Gehen Sie zu Benutzereinstellungen → Zugriffstoken und notieren Sie sich das Token:

Konto zum Empfang des Tokens
Durch den API-Zugriff können Sie fast alles mit Ihren Repositorys machen. Ich empfehle Ihnen daher, ein separates Gitlab-Konto zu erstellen, ihm minimale Rechte für Ihre Repositorys (wie Reporter) zu erteilen und ein Token für dieses Konto zu erhalten.

2. Fügen Sie das Token zu Gitlab-Variablen hinzu

Im vorherigen Schritt haben wir beispielsweise einen Token erhalten QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Öffnen Sie Einstellungen → CI/CD → Variablen → Variable hinzufügen → GITLAB_TOKEN_FOR_CI

Als Ergebnis erhalten wir:

Dies kann sowohl für ein Repository als auch für eine Gruppe von Repositorys erfolgen.

3. Wir verbieten Merge, wenn die Genehmigung der Kollegen nach der Codeüberprüfung nicht eingeht

In unserem Fall besteht das Verbot von Merge darin, dass die Assembly-Pipeline einen Fehler zurückgibt, wenn nicht genügend Stimmen vorhanden sind.

Gehen Sie zu Einstellungen → Allgemein → Zusammenführungsanforderungen → Zusammenführungsprüfungen und aktivieren Sie die Option „Montagelinien müssen erfolgreich ausgeführt werden“.

4. Richten Sie die Pipeline ein

Wenn Sie noch keine CI/CD-Pipeline für Ihre Anwendung erstellt haben
Erstellen Sie eine Datei im Stammverzeichnis des Repositorys .gitlab-ci.yml mit einfachem Inhalt:

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"

Separates Repository für die CI/CD-Konfiguration
Ich würde empfehlen, ein separates Repository zu erstellen, in dem Sie eine myapp.gitlab-ci.yml-Datei erstellen müssen, um die Pipeline einzurichten. Auf diese Weise können Sie den Zugriff von Mitwirkenden besser kontrollieren, die die Build-Pipeline ändern und ein Zugriffstoken erhalten können.

Der Speicherort der neuen Pipeline-Datei muss angegeben werden, indem Sie zum myapp-Repository gehen – Einstellungen – CI/CD – Fertigungslinien – Benutzerdefinierter CI-Konfigurationspfad – geben Sie beispielsweise eine neue Datei an myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Tipp: Verwenden Sie einen Linter, um Änderungen an GitLab CI-Dateien vorzunehmen
Selbst wenn Sie alleine arbeiten, ist die Arbeit mit MR ein guter Helfer, da alle Ihre Änderungen an den Pipeline-Dateien über den Linter ausgeführt werden. Wenn Sie einen Fehler in der Syntax der YAML-Datei machen, können Sie dadurch die funktionierende Pipeline nicht unterbrechen, sondern Merge einfach blockieren.

Ein Beispiel für Container mit Linters, die Sie in Ihre Pipeline einbetten können:

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

Und ein Beispiel für die Validierungsphase:

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;

Es müssen noch einige Parameter zu Ihrer Pipeline hinzugefügt werden, damit sie funktioniert:

stages:
- test

variables:
NEED_VOTES: 1

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

Die Variable NEED_VOTES bestimmt, wie viele „Daumen hoch“ MR haben muss, damit Merge verfügbar ist. Ein Wert von eins bedeutet, dass Sie Ihren MR selbst genehmigen können, indem Sie ihn „liken“.

include beinhaltet die Testphase, die die Anzahl der „Likes“ prüft.

Die einfachste Pipeline am Beispiel 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

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


Erfahren Sie mehr darüber, was bei der Überprüfung passiert:

• Es ist die Einschränkung festgelegt, dass die Prüfung nur dann erfolgt, wenn ein MR in den Zweigen master oder release /* erstellt wird
• Ermitteln Sie mithilfe der GitLab-API die Anzahl der „Likes“ und „Dislikes“.
• Berechnen Sie die Differenz zwischen positiven und negativen Antworten
• Wenn die Differenz kleiner ist als der Wert, den wir in NEED_VOTES festgelegt haben, blockieren wir die Möglichkeit zur Zusammenführung

5. Deaktivieren Sie Commits für geschützte Zweige

Wir legen die Zweige fest, für die wir eine Codeüberprüfung durchführen sollten, und weisen darauf hin, dass mit ihnen nur über MR gearbeitet werden kann.

Gehen Sie dazu zu Einstellungen → Repository → Geschützte Zweige:

6. Überprüfung

Setzen Sie NEED_VOTES: 0

Wir machen MR und setzen ein „Dislike“.

In den Build-Protokollen:

Geben Sie nun „Gefällt mir“ ein und führen Sie eine erneute Überprüfung durch:

Source: habr.com