Kodearen berrikuspena Gitlab CE-n: bateratze eskaeraren onespenik ez badago, baina benetan nahi dut

Funtzio beharrezkoenetako bat, GitLab-en doako bertsioan ez dagoena, biltegiaren baliogabetzearen aurka bozkatzeko eta bateratzeko eskaera (MR) kontrolatzeko gaitasuna da, derrigorrezko kodearen berrikuspena erabiliz.

Egin ditzagun gutxieneko funtzionaltasuna geuk: Merge debekatuko dugu hainbat garatzailek MRri harrera eman arte.

Zergatik da hau ere beharrezkoa?

Gure erakundeak erraz ordaindu dezake GitLab lizentzia bat erostea. Baina, garapena Interneterako sarbiderik gabeko begizta itxian egiten denez, eta aurrekontuen planifikazio zorrotza dagoenez, beharrezko funtzionaltasuna duten lizentzia autogestionatuak erostea hilabete asko luzatzen da, baina lana egin behar da orain.

Ondorioz, honako hau egin behar duzu:

• edo Garatzaile batzuentzat babestutako adarretan bateratzea guztiz debekatu, baina gero bateratzeko eskubidea duten garatzaileek gatazkak jasotzen dituzte besteen MR-ak bateratzean bonus gisa;
• edo zure adar nagusiarekin kontrolik gabeko bateraketak egiteko aukera eman kodea berrikuspenik gabe, nahiz eta atzo kontratatu zuten Junior izan.

Egin nuen lehen gauza Google izan zen, norbaitek behin betiko antzeko zerbait egin zuela (kodea aldatu gabe) uste baitzuen, baina komunitatearen bertsioan oraindik ez zegoela halako inplementaziorik gertatu zen.

Lan-eskema orokorra

Adibide gisa, konfigura ditzagun bateratze eskaeraren onarpenak proba-biltegi batean nireaplikazioa:

1. Sortu dezagun GitLab APIra sartzeko token bat (horren bidez "alde" eta "kontrako" boto kopuruari buruzko informazioa jasoko dugu.
2. Gehi dezagun tokena GitLab aldagaietan
3. Desgaitu dezagun bateratzea kanalizazioan akatsen kasuan (boto nahikorik ez badago)
4. Konfigura dezagun boto-egiaztapena CI/CD kanalaren zati gisa
5. Debekatzen dugu babestutako sukurtsaletarako konpromisoak egitea; aldaketa guztiak MR bidez bakarrik egiten dira
6. Ikus dezagun azkenean zer gertatu den

1. Sortu token bat APIra sartzeko

Joan Erabiltzailearen ezarpenak → Sarbide-tokenak atalera eta idatzi tokena:

Token bat jasotzeko kontua
API sarbideak zure biltegiekin ia edozer gauza egiteko aukera ematen dizu, beraz, Gitlab kontu bereizi bat sortzea gomendatzen dut, zure biltegiei gutxieneko eskubideak emanez (adibidez, Reporter) eta kontu horretarako token bat eskuratzea.

2. Gehitu tokena Gitlab aldagaietara

Adibidez, aurreko urratsean token bat jaso genuen QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Ireki Ezarpenak → CI/CD → Aldagaiak → Gehitu aldagaia → GITLAB_TOKEN_FOR_CI

Ondorioz lortzen dugu:

Hau biltegi batean edo biltegi talde batean egin daiteke.

3. Merge debekua jartzen dugu, baldin eta lankideen onespena jasotzen ez bada kodea berrikusi ondoren.

Gure kasuan, Bateratzearen debekua izango da muntaketa-hodiak akats bat itzuliko duela boto nahikorik ez badago.

Joan Ezarpenak → Orokorra → Bateratu eskaerak → Bateratu egiaztapenak eta gaitu Muntaketa-lerroak behar bezala burutu behar dira aukera.

4. Kanalizazioa konfiguratzea

Oraindik ez baduzu sortu CI/CD kanalizaziorik zure aplikaziorako
Sortu fitxategi bat biltegiaren erroan .gitlab-ci.yml edukirik errazena duena:

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 konfiguraziorako biltegi bereizia
Gordetegi bereizi bat egitea gomendatuko nuke eta bertan myapp.gitlab-ci.yml fitxategi bat sortu behar duzu kanalizazioa konfiguratzeko. Horrela, hobeto kontrolatu ahal izango duzu eraikuntza kanalizazioa alda dezaketen parte-hartzaileen sarbidea eta sarbide-token bat jasotzeko.

Pipeline fitxategi berriaren kokapena zehaztu beharko da myapp biltegira joanez - Ezarpenak - CI/CD - Muntaketa lerroak - CI pertsonalizatuaren konfigurazio bide - zehaztu fitxategi berria, adibidez. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Aholkua: Erabili linter bat GitLab CI fitxategietan aldaketak egiteko
Bakarrik lan egiten baduzu ere, MR bidez lan egitea laguntza ona izango da, kanalizazio fitxategietan egin dituzun aldaketa guztiak linter baten bidez exekutatzen. YAML fitxategiaren sintaxian akatsen bat egiten baduzu, ez du zure ekoizpen kanalizazioa hautsiko, baizik eta Bateratzea blokeatuko du.

Zure kanalizazioan txerta ditzakezun linters duten ontzien adibide bat:

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

Eta egiaztapen fasearen adibide bat:

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;

Zure kanalizazioan parametro batzuk gehitzea geratzen da funtziona dezan:

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 aldagaiak zehazten du zenbat erpuru izan behar dituen MR Merge erabilgarri egon dadin. Baten balio batek esan nahi du zuk zeuk onar dezakezula zure MR "gustatu" eginez.

include proba-fasea barne hartzen du, "atsegin dut" kopurua egiaztatzen duena.

kanalizazio sinpleena myapp.gitlab-ci.yml adibidea erabiliz
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

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


Egiaztapenean gertatzen denari buruzko informazio gehiago:

• murrizketa bat dago egiaztapena maisuan edo oharra/* adarretan MR sortzean bakarrik egingo dela
• GitLab APIa erabiliz, "atsegin dut" eta "gustatu ez" kopurua lortuko dugu
• kalkulatu erantzun positiboen eta negatiboen arteko aldea
• aldea NEED_VOTES-en ezarri dugun balioa baino txikiagoa bada, batzeko gaitasuna blokeatzen dugu

5. Babestutako sukurtsalekiko konpromisoak debekatu

Kodeen berrikuspenak egin behar ditugun adarrak definitzen ditugu eta MR bidez soilik lan egin daitekeela adierazten dugu.

Horretarako, joan Ezarpenak → Biltegia → Adar babestuak:

6. Egiaztatu

Ezarri NEED_VOTES: 0

MR bat egiten dugu eta "ez gustatu" bat jartzen diogu.

Eraikuntza-erregistroetan:

Orain jarri "atsegin dut" eta hasi berriro egiaztatzen:

Iturria: www.habr.com