🥇Կոդերի վերանայում Gitlab CE-ում. եթե Միաձուլման հարցումների հաստատումներ չկան, բայց դուք իսկապես ցանկանում եք

Ամենաանհրաժեշտ գործառույթներից մեկը, որը չկա GitLab-ի անվճար տարբերակում, պահեստի չեղյալ հայտարարման դեմ քվեարկելու և Միաձուլման հարցումը (MR) վերահսկելու հնարավորությունն է՝ օգտագործելով կոդերի պարտադիր վերանայումը։

Եկեք ինքներս անենք նվազագույն ֆունկցիոնալությունը. մենք կարգելենք Merge-ը, քանի դեռ մի քանի ծրագրավորողներ MR-ին ձեռք չեն տվել:

Ինչու է դա նույնիսկ անհրաժեշտ:

Մեր կազմակերպությունը կարող է հեշտությամբ իրեն թույլ տալ գնել GitLab լիցենզիա: Բայց քանի որ զարգացումն իրականացվում է փակ օղակով, առանց ինտերնետ հասանելիության, և կա բյուջեի խիստ պլանավորում, անհրաժեշտ ֆունկցիոնալությամբ ինքնակառավարվող լիցենզիաների գնումը կարող է երկարաձգվել երկար ամիսներ, բայց հիմա աշխատանք պետք է կատարվի:

Արդյունքում դուք պետք է.

կամ ամբողջությամբ արգելել Միաձուլումը պաշտպանված ճյուղերում որոշ ծրագրավորողների համար, բայց այնուհետև Միաձուլման իրավունք ունեցող ծրագրավորողները ստանում են կոնֆլիկտներ այլ մարդկանց MR-ները միավորելիս որպես բոնուս.
կամ հնարավորություն տվեք անվերահսկելի միաձուլումներ կատարել ձեր գլխավոր մասնաճյուղի հետ առանց ծածկագրի վերանայման, նույնիսկ եթե դա Ջունիորն է, ով աշխատանքի է ընդունվել հենց երեկ:

Առաջին բանը, որ արեցի Google-ն էր՝ հավատալով, որ ինչ-որ մեկը հաստատ արդեն արել է նման բան (առանց կոդը փոփոխելու), բայց պարզվեց, որ համայնքի տարբերակում դեռ նման ներդրում չկա։

Աշխատանքի ընդհանուր սխեման

Որպես օրինակ, եկեք կարգավորենք Merge-ի հարցումների հաստատումները թեստային պահոցում myapp:

Եկեք ստեղծենք GitLab API մուտք գործելու նշան (դրա միջոցով մենք տեղեկատվություն կստանանք «կողմ» և «դեմ» ձայների քանակի մասին)
Եկեք ավելացնենք նշանը GitLab փոփոխականներին
Եկեք անջատենք Merge-ը խողովակաշարում սխալների դեպքում (եթե բավարար կողմ ձայներ չկան)
Եկեք ստեղծենք քվեարկության ստուգումը որպես CI/CD խողովակաշարի մաս
Մենք արգելում ենք պարտավորություններ կատարել պաշտպանված մասնաճյուղերի նկատմամբ, բոլոր փոփոխությունները կատարվում են միայն MR-ի միջոցով
Եկեք ստուգենք, թե ինչ եղավ վերջում

1. Ստեղծեք նշան՝ API մուտք գործելու համար

Գնացեք «Օգտատիրոջ կարգավորումներ» → «Մուտքի նշաններ» և գրեք նշանը.

Հաշիվ՝ նշան ստանալու համար
API մուտքը թույլ է տալիս գրեթե ամեն ինչ անել ձեր պահոցների հետ, ուստի խորհուրդ եմ տալիս ստեղծել առանձին Gitlab հաշիվ՝ նվազագույն իրավունքներ տալով ձեր պահեստներին (օրինակ՝ Reporter) և ստանալ այդ հաշվի համար նշան:

2. Ավելացրեք նշանը Gitlab փոփոխականներին

Օրինակ, նախորդ քայլում մենք ստացել ենք նշան QmN2Y0NOUFlfeXhvd21ZS01aQzgK

Բացեք Կարգավորումներ → CI/CD → Փոփոխականներ → Ավելացնել փոփոխական → GITLAB_TOKEN_FOR_CI

Արդյունքում մենք ստանում ենք.

Դա կարելի է անել կամ մեկ պահեստի կամ պահեստների խմբի վրա:

3. Մենք արգելանք ենք դնում Merge-ի վրա, եթե կոլեգաների հավանությունը չստացվի կոդի վերանայումից հետո:

Մեր դեպքում, Merge-ի արգելքը կլինի այն, որ հավաքման խողովակաշարը սխալ կհայտնի, եթե բավարար ձայներ չկան:

Գնացեք Կարգավորումներ → Ընդհանուր → Միաձուլման հարցումներ → Միաձուլման ստուգումներ և միացրեք այն տարբերակը, որ հավաքման տողերը պետք է հաջողությամբ ավարտվեն:

4. Խողովակաշարի տեղադրում

Եթե դուք դեռ չեք ստեղծել CI/CD խողովակաշար ձեր հավելվածի համար
Ստեղծեք ֆայլ պահեստի արմատում .gitlab-ci.yml ամենապարզ բովանդակությամբ.

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 կազմաձևման համար
Ես խորհուրդ կտայի ստեղծել առանձին պահեստ, որտեղ խողովակաշարը կարգավորելու համար պետք է ստեղծեք myapp.gitlab-ci.yml ֆայլ: Այս կերպ Դուք կարող եք ավելի լավ վերահսկել մասնակիցների մուտքը, ովքեր կարող են փոխել կառուցման խողովակաշարը և ստանալ մուտքի նշան:

Նոր խողովակաշարի ֆայլի գտնվելու վայրը պետք է ճշտվի՝ գնալով myapp-ի պահոց - Կարգավորումներ - CI/CD - հավաքման տողեր - Պատվերով CI կազմաձևման ուղի - նշեք նոր ֆայլը, օրինակ. myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci

Հուշում. GitLab CI ֆայլերում փոփոխություններ անելու համար օգտագործեք լինտեր
Նույնիսկ եթե դուք մենակ եք աշխատում, MR-ի միջոցով աշխատելը լավ օգնություն կլինի՝ ձեր բոլոր փոփոխությունները խողովակաշարի ֆայլերի մեջ ներբեռնելու միջոցով: Եթե սխալ եք թույլ տալիս YAML ֆայլի շարահյուսության մեջ, դա չի կոտրի ձեր արտադրական խողովակաշարը, այլ պարզապես արգելափակում է Merge-ը:

Լինտերով բեռնարկղերի օրինակ, որոնք կարող եք կառուցել ձեր խողովակաշարի մեջ.

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

Եվ ստուգման փուլի օրինակ.

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;

Մնում է մի քանի պարամետր ավելացնել ձեր խողովակաշարին, որպեսզի այն աշխատի.

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 փոփոխականը որոշում է, թե քանի «բթամատ» MR պետք է ունենա, որպեսզի Merge-ը հասանելի լինի: Մեկին հավասար արժեքը նշանակում է, որ դուք ինքներդ կարող եք հաստատել ձեր MR՝ «հավանելով» այն:

ներառումը ներառում է թեստային փուլը, որը ստուգում է «լայքերի» թիվը:

Ամենապարզ խողովակաշարը՝ օգտագործելով 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

Բովանդակությունը 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/.*$/'

Լրացուցիչ տեղեկություններ այն մասին, թե ինչ է տեղի ունենում ստուգման ընթացքում.

կա սահմանափակում, որ ստուգումը կկատարվի միայն Master-ի կամ Release/* ճյուղերում MR ստեղծելու ժամանակ
օգտագործելով GitLab API-ը, մենք ստանում ենք «հավանումներ» և «չհավանումներ» թիվը:
հաշվարկել դրական և բացասական պատասխանների տարբերությունը
եթե տարբերությունը փոքր է այն արժեքից, որը մենք սահմանել ենք NEED_VOTES-ում, ապա մենք արգելափակում ենք միաձուլվելու հնարավորությունը

5. Արգելեք պարտավորությունները պաշտպանված մասնաճյուղերի նկատմամբ

Մենք սահմանում ենք այն մասնաճյուղերը, որոնց համար մենք պետք է անցկացնենք կոդերի վերանայում և նշում, որ դրանց հետ կարելի է աշխատել միայն MR-ի միջոցով:

Դա անելու համար անցեք Կարգավորումներ → Պահեստ → Պաշտպանված մասնաճյուղեր:

6. Ստուգեք

Սահմանել NEED_VOTES՝ 0

Մենք MR ենք անում և դնում «dislike»:

Կառուցման տեղեկամատյաններում.

Այժմ դրեք «like» և նորից սկսեք ստուգել.

Source: www.habr.com

Կոդի վերանայում Gitlab CE-ում. եթե չկա Միաձուլման հարցումների հաստատումներ, բայց ես իսկապես ուզում եմ