Ես հաճախ ստիպված եմ խողովակաշար կառուցել Java-ում նախագծեր կառուցելու համար: Երբեմն դա բաց կոդով է, երբեմն՝ ոչ: Վերջերս ես որոշեցի փորձել տեղափոխել իմ պահոցներից մի քանիսը Travis-CI-ից և TeamCity-ից GitHub Actions, և ահա թե ինչ դուրս եկավ դրանից:
Ի՞նչ ենք ավտոմատացնելու:
Նախ, մեզ անհրաժեշտ է նախագիծ, որը մենք ավտոմատացնելու ենք, եկեք մի փոքրիկ հավելված ստեղծենք Spring boot / Java 11 / Maven-ում: Այս հոդվածի նպատակների համար մեզ ընդհանրապես չի հետաքրքրի հավելվածի տրամաբանությունը, մեզ համար կարևոր է հավելվածի շուրջ ենթակառուցվածքը, ուստի մեզ համար բավական կլինի պարզ REST API կարգավորիչը:
Աղբյուրները կարող եք դիտել այստեղ՝ Խողովակաշարի կառուցման բոլոր փուլերն արտացոլված են այս նախագծի ձգման հարցումներում:
JIRA և պլանավորում
Արժե ասել, որ մենք սովորաբար օգտագործում ենք JIRA-ն որպես խնդիրների հետագծող, ուստի եկեք ստեղծենք առանձին տախտակ այս նախագծի համար և այնտեղ ավելացնենք առաջին խնդիրները.
Քիչ ուշ մենք կանդրադառնանք նրան, թե ինչ հետաքրքիր բաներ կարող են առաջարկել JIRA-ն և GitHub-ը համատեղությամբ։
Մենք ավտոմատացնում ենք նախագծի հավաքումը
Մեր փորձնական նախագիծը կառուցված է maven-ի միջոցով, ուստի այն կառուցելը բավականին պարզ է, մեզ միայն անհրաժեշտ է mvn մաքուր փաթեթը:
Դա անելու համար, օգտագործելով Github Actions, մենք պետք է շտեմարանում ստեղծենք ֆայլ, որը նկարագրում է մեր աշխատանքային հոսքը, դա կարելի է անել սովորական yml ֆայլով, չեմ կարող ասել, որ ես սիրում եմ «yml ծրագրավորումը», բայց ինչ կարող ենք անել. մենք դա անում ենք .github/ directory workflow/ ֆայլ build.yml, որտեղ մենք նկարագրելու ենք հիմնական մասնաճյուղը կառուցելիս գործողությունները.
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean package -DskipTests
on — սա այն իրադարձության նկարագրությունն է, որով մեկնարկելու է մեր սցենարը:
վրա՝ pull_request/push — ցույց է տալիս, որ այս աշխատանքային հոսքը պետք է գործարկվի ամեն անգամ, երբ հպում է կատարվում վարպետին և ստեղծվում են ձգման հարցումներ:
Ստորև ներկայացված է առաջադրանքների նկարագրությունը (Աշխատանք) և կատարման քայլերը (քայլեր) յուրաքանչյուր առաջադրանքի համար:
վազում է - այստեղ մենք կարող ենք ընտրել թիրախային OS, զարմանալիորեն, նույնիսկ կարող եք ընտրել Mac OS, բայց մասնավոր պահեստներում դա բավականին թանկ է (համեմատած Linux-ի հետ):
uses թույլ է տալիս նորից օգտագործել այլ գործողություններ, օրինակ՝ օգտագործելով actions/setup-java գործողությունը, մենք տեղադրում ենք միջավայրը Java 11-ի համար:
Միջոցով հետ մենք կարող ենք նշել այն պարամետրերը, որոնցով մենք սկսում ենք գործողությունը, ըստ էության, սրանք այն փաստարկներն են, որոնք փոխանցվելու են գործողությանը:
Մնում է միայն գործարկել նախագիծը Maven-ում. run: mvn -B clean package դրոշ -B ասում է, որ մեզ պետք է ոչ ինտերակտիվ ռեժիմ, որպեսզի այրը հանկարծ չուզենա մեզ ինչ-որ բան հարցնել
Հիանալի Այժմ, ամեն անգամ, երբ դուք պարտավորվում եք վարպետին, նախագծի կառուցումը սկսվում է:
Թեստային գործարկումների ավտոմատացում
Մոնտաժումը լավ է, բայց իրականում նախագիծը կարելի է ապահով հավաքել, բայց ոչ աշխատել: Հետևաբար, հաջորդ քայլը փորձարկման գործարկումների ավտոմատացումն է: Բացի այդ, բավականին հարմար է դիտել թեստերը հանձնելու արդյունքները, երբ դուք PR վերանայում եք անում. դուք հաստատ գիտեք, որ թեստերն անցնում են, և ոչ ոք չի մոռացել գործարկել իր մասնաճյուղը նախքան միաձուլումը:
Մենք փորձարկումներ կկատարենք ձգման հարցում ստեղծելիս և կմիավորվենք հիմնականին, և միևնույն ժամանակ կավելացնենք կոդերի ծածկույթի վերաբերյալ զեկույցի ստեղծումը։
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Verify
run: mvn -B clean verify
- name: Test Coverage
uses: codecov/codecov-action@v1
with:
token: ${{ secrets.CODECOV_TOKEN }}
Թեստերը լուսաբանելու համար ես օգտագործում եմ codecov jacoco հավելվածի հետ համատեղ: codecov-ն ունի իր սեփական գործողությունը, բայց նրան անհրաժեշտ է նշան, որպեսզի աշխատի մեր ձգման խնդրանքով.
${{ secrets.CODECOV_TOKEN }} — մենք կտեսնենք այս կոնստրուկցիան մեկից ավելի անգամ, գաղտնիքը GitHub-ում գաղտնիքները պահելու մեխանիզմ է, մենք կարող ենք այնտեղ գրել գաղտնաբառեր/tokens/host/url և այլ տվյալներ, որոնք չպետք է ներառվեն պահեստի կոդերի բազայում։
Դուք կարող եք փոփոխական ավելացնել գաղտնիքներին GitHub-ի պահեստի կարգավորումներում.
Դուք կարող եք ստանալ նշան է GitHub-ի միջոցով թույլտվությունից հետո հանրային նախագիծ ավելացնելու համար պարզապես անհրաժեշտ է հետևել հետևյալ հղմանը. /[repo name]: Կարող է նաև մասնավոր պահոց ավելացվել, դրա համար պետք է Github-ում հավելվածին տալ codecov իրավունք:
Ավելացնել jacoco հավելվածը POM ֆայլին.
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<!-- attached to Maven test phase -->
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<reportFormat>plain</reportFormat>
<includes>
<include>**/*Test*.java</include>
<include>**/*IT*.java</include>
</includes>
</configuration>
</plugin>
Այժմ codecov բոտը կմտնի մեր ձգման հարցումներից յուրաքանչյուրը և կավելացնի ծածկույթի փոփոխության գրաֆիկ.
Եկեք ավելացնենք ստատիկ անալիզատոր
Իմ բաց կոդով նախագծերի մեծ մասում ես օգտագործում եմ սոնար ամպ ստատիկ կոդի վերլուծության համար, բավականին հեշտ է միանալ travis-ci-ին: Այսպիսով, դա տրամաբանական քայլ է, երբ տեղափոխվում եք GitHub Actions՝ նույնն անել: Ակցիայի շուկան հիանալի բան է, բայց այս անգամ այն ինձ մի փոքր հուսահատեցրեց, քանի որ սովորությունից ելնելով գտա այն ակցիան, որն ինձ անհրաժեշտ էր և ավելացրի այն աշխատանքային գործընթացին: Բայց պարզվեց, որ սոնարը չի աջակցում Maven-ի կամ gradle-ի նախագծերի վերլուծության ակցիային: Իհարկե, սա գրված է փաստաթղթերում, բայց ո՞վ է կարդում:
Գործողության միջոցով դա հնարավոր չէ, ուստի մենք դա կանենք mvn հավելվածի միջոցով.
name: SonarCloud
on:
push:
branches:
- master
pull_request:
types: [opened, synchronize, reopened]
jobs:
sonarcloud:
runs-on: ubuntu-16.04
steps:
- uses: actions/checkout@v1
- name: Set up JDK
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Analyze with SonarCloud
# set environment variables:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# run sonar maven plugin:
run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml
SONAR_TOKEN - կարելի է ձեռք բերել և դուք պետք է գրանցեք այն գաղտնիքներում: GITHUB_TOKEN - սա ներկառուցված նշան է, որը ստեղծում է GitHub-ը, որի օգնությամբ sonarcloud[bot]-ը կկարողանա մուտք գործել Git, որպեսզի մեզ հաղորդագրություններ թողնի ձգման հարցումներում:
Dsonar.projectKey — նախագծի անվանումը սոնարում, այն կարող եք տեսնել նախագծի կարգավորումներում:
Dsonar.organization — կազմակերպության անվանումը GitHub-ից:
Մենք դիմում ենք քաշելու հարցում և սպասում, որ sonarcloud[bot]-ը գա մեկնաբանություններում.
Ազատ արձակելը
Բիլդը կազմաձևվել է, թեստերն իրականացվել են, և մենք կարող ենք թողարկել: Եկեք նայենք, թե ինչպես GitHub Actions-ը կարող է շատ ավելի հեշտացնել թողարկման կառավարումը:
Աշխատանքի ժամանակ ես ունեմ նախագծեր, որոնց կոդերի բազան գտնվում է bitbucket-ում (ամեն ինչ նման է այդ պատմության «Ես գրում եմ bitbucket-ին ցերեկը, պարտավորվում եմ GitHub-ին գիշերը»): Ցավոք, bitbucket-ը չունի ներկառուցված թողարկման կառավարման գործիքներ: Սա խնդիր է, քանի որ յուրաքանչյուր թողարկման համար դուք պետք է ձեռքով էջ ստեղծեք միաձուլման մեջ և այնտեղ գցեք թողարկման մեջ ներառված բոլոր հնարավորությունները, որոնեք մտքի պալատները, առաջադրանքները jira-ում, պարտավորություններ պահոցում: Սխալվելու շատ հնարավորություններ կան, դուք կարող եք մոռանալ ինչ-որ բան կամ մուտքագրել մի բան, որն արդեն թողարկվել է նախորդ անգամ, երբեմն պարզապես պարզ չէ, թե ինչ պետք է դասակարգել pull-ի հարցումը. ինչ-որ ենթակառուցվածքային.
Ինչպե՞ս կարող են մեզ օգնել GitHub-ի գործողությունները: Գոյություն ունի հիանալի գործողություն՝ թողարկման նախագծող, այն թույլ է տալիս սահմանել թողարկման նշումների ֆայլի ձևանմուշ՝ ձգման հարցումների կատեգորիաներ ստեղծելու և դրանք ավտոմատ կերպով խմբավորելու թողարկման նշումների ֆայլում.
Զեկույց ստեղծելու օրինակելի ձևանմուշ (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' New Features'
labels:
- 'type:features'
# в эту категорию собираем все PR с меткой type:features
- title: ' Bugs Fixes'
labels:
- 'type:fix'
# аналогично для метки type:fix и т.д.
- title: ' Documentation'
labels:
- 'type:documentation'
- title: ' Configuration'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Changes
$CHANGES
Ավելացրեք սցենար՝ թողարկման սևագիր ստեղծելու համար (.github/workflows/release-draft.yml):
name: "Create draft release"
on:
push:
branches:
- master
jobs:
update_draft_release:
runs-on: ubuntu-18.04
steps:
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Ներգրավման բոլոր հարցումներն այսուհետ ինքնաբերաբար կհավաքվեն թողարկման նշումներում՝ կախարդական:
Այստեղ կարող է հարց առաջանալ՝ իսկ եթե մշակողները մոռանան PR-ում պիտակներ տեղադրել։ Հետո պարզ չէ, թե որ կատեգորիայի մեջ դնել, և նորից պետք է ձեռքով զբաղվես, յուրաքանչյուր PR-ով առանձին։ Այս խնդիրը շտկելու համար մենք կարող ենք օգտագործել մեկ այլ գործողություն՝ պիտակի ստուգիչ. այն ստուգում է պիտակների առկայությունը ձգման հարցում: Եթե չկան պահանջվող պիտակներ, ապա ստուգումը չի հաջողվի, և մենք այս մասին հաղորդագրություն կտեսնենք մեր ձգման հարցումում:
name: "Verify type labels"
on:
pull_request:
types: [opened, labeled, unlabeled, synchronize]
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: zwaldowski/match-label-action@v2
with:
allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'
Այժմ ցանկացած pull-խնդրանք պետք է նշվի պիտակներից մեկով՝ type:fix, type:features, type:documentation, type:tests, type:config:
Ձգման հարցումների ավտոմատ նշում
Քանի որ մենք շոշափեցինք այնպիսի թեմա, ինչպիսին է արդյունավետ աշխատանքը ձգման հարցումների հետ, արժե խոսել այնպիսի գործողության մասին, ինչպիսին է պիտակավորողը, այն PR-ում պիտակներ է դնում, որոնց հիման վրա ֆայլերը փոխվել են: Օրինակ, մենք կարող ենք նշել որպես [build] ցանկացած ձգման հարցում, որը պարունակում է փոփոխություններ գրացուցակում .github/workflow.
Միացնելը բավականին պարզ է.
name: "Auto-assign themes to PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Մեզ նաև անհրաժեշտ է ֆայլ, որը նկարագրում է նախագծի դիրեկտորիաների և ձգման հարցումների թեմաների համապատասխանությունը.
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Ինձ չհաջողվեց զուգակցել գործողությունը, որն ավտոմատ կերպով պիտակները տեղադրում է ձգման հարցումների մեջ, այն գործողության հետ, որը ստուգում է պահանջվող պիտակների առկայությունը. match-label-ը չի ցանկանում տեսնել բոտի կողմից ավելացված պիտակները: Թվում է, թե ավելի հեշտ է գրել ձեր սեփական գործողությունը, որը համատեղում է երկու փուլերը: Բայց նույնիսկ այս ձևով այն բավականին հարմար է օգտագործել, դուք պետք է ընտրեք պիտակ ցանկից, երբ ստեղծում եք քաշման հարցում:
Ժամանակն է տեղակայել
Ես փորձեցի տեղակայման մի քանի տարբերակներ GitHub Actions-ի միջոցով (ssh-ի միջոցով, scp-ի միջոցով և docker-hub-ի միջոցով), և կարող եմ ասել, որ, ամենայն հավանականությամբ, դուք կգտնեք երկուականը սերվեր վերբեռնելու միջոց, անկախ նրանից, թե որքան ծուռ է ձեր խողովակաշարը: է.
Ինձ դուր եկավ ամբողջ ենթակառուցվածքը մեկ տեղում պահելու տարբերակը, ուստի եկեք նայենք, թե ինչպես տեղակայել GitHub փաթեթներում (սա երկուական բովանդակության, npm, բանկա, դոկերի պահեստ է):
Դոկերի պատկեր ստեղծելու և այն GitHub փաթեթներում հրապարակելու սցենար.
name: Deploy docker image
on:
push:
branches:
- 'master'
jobs:
build_docker_image:
runs-on: ubuntu-18.04
steps:
# Build JAR:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean compile package -DskipTests
# Set global environment variables:
- name: set global env
id: global_env
run: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"
# Build Docker image:
- name: Build and tag image
run: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- name: Docker login
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publish image to github package repository:
- name: Publish image
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Նախ, մենք պետք է կառուցենք մեր հավելվածի JAR ֆայլը, որից հետո հաշվում ենք դեպի GitHub դոկերի ռեեստրի ուղին և մեր պատկերի անունը։ Այստեղ կան մի քանի հնարքներ, որոնց մենք դեռ չենք հանդիպել.
- echo «::set-output name=NAME::VALUE» կոնստրուկցիան թույլ է տալիս ընթացիկ քայլում սահմանել փոփոխականի արժեքը, որպեսզի այն հնարավոր լինի կարդալ մնացած բոլոր քայլերում:
- Դուք կարող եք ստանալ նախորդ քայլում սահմանված փոփոխականի արժեքը այս քայլի նույնացուցիչի միջոցով՝ ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Ստանդարտ GITHUB_REPOSITORY փոփոխականը պահում է պահեստի և դրա սեփականատիրոջ անունը («սեփականատեր/ռեպո-անուն»): Այս տողից ամեն ինչ կտրելու համար, բացի պահեստի անունից, մենք կօգտագործենք bash շարահյուսություն՝ ${GITHUB_REPOSITORY#*/}
Հաջորդը մենք պետք է կառուցենք դոկերի պատկերը.
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Մուտք գործեք գրանցամատյան.
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Եվ նկարը հրապարակեք GitHub Packages Repository-ում.
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Պատկերի տարբերակը նշելու համար մենք օգտագործում ենք կոմմիթի SHA հեշից առաջին թվանշանները՝ GITHUB_SHA, այստեղ կան նաև նրբերանգներ, եթե այդպիսի կառուցումներ եք անում ոչ միայն վարպետին միաձուլվելիս, այլ նաև ըստ pull-հայտի ստեղծման։ իրադարձությունը, ապա SHA-ն կարող է չհամընկնել հեշի հետ, որը մենք տեսնում ենք git պատմության մեջ, քանի որ գործողությունների/ստուգման գործողությունը ստեղծում է իր յուրահատուկ հեշը՝ PR-ում փակուղային գործողություններից խուսափելու համար:
Եթե ամեն ինչ լավ ստացվեց, ապա բացելով փաթեթների բաժինը (https://github.com/antkorwin/github-actions/packages) պահոցում, կտեսնեք նոր դոկերի պատկեր.
Այնտեղ կարող եք տեսնել նաև դոկերի պատկերի տարբերակների ցանկը:
Մնում է միայն կարգավորել մեր սերվերը այս ռեեստրի հետ աշխատելու համար և վերագործարկել ծառայությունը: Ես հավանաբար կխոսեմ այն մասին, թե ինչպես դա անել համակարգի միջոցով մեկ այլ անգամ:
Մոնիտորինգ
Եկեք նայենք մի պարզ տարբերակի, թե ինչպես կարելի է առողջական ստուգում կատարել մեր հավելվածի համար՝ օգտագործելով GitHub Actions-ը: Մեր բեռնախցիկի հավելվածն ունի ակտիվացուցիչ, ուստի մենք նույնիսկ կարիք չունենք API գրելու՝ դրա կարգավիճակը ստուգելու համար, մենք արդեն ամեն ինչ արել ենք ծույլերի համար: Դուք պարզապես պետք է քաշեք տանտիրոջը. SERVER-URL:PORT/actuator/health
$ curl -v 127.0.0.1:8080/actuator/health
> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*
< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT
{"status":"UP"}
Մեզ անհրաժեշտ է միայն cron-ի միջոցով սերվերը ստուգելու առաջադրանք գրել, և եթե հանկարծ այն մեզ չպատասխանի, ապա մենք ծանուցում կուղարկենք հեռագրով։
Նախ, եկեք պարզենք, թե ինչպես վարել cron աշխատանքային հոսքը.
on:
schedule:
- cron: '*/5 * * * *'
Դա պարզ է, ես նույնիսկ չեմ կարող հավատալ, որ Github-ում դուք կարող եք ստեղծել իրադարձություններ, որոնք ընդհանրապես չեն տեղավորվում վեբ-կեռիկների մեջ: Մանրամասները ներկայացված են փաստաթղթերում.
Եկեք ստուգենք սերվերի կարգավիճակը ձեռքով curl-ի միջոցով.
jobs:
ping:
runs-on: ubuntu-18.04
steps:
- name: curl actuator
id: ping
run: |
echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"
- name: health check
run: |
if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
echo "health check is failed"
exit 1
fi
echo "It's OK"
Սկզբում մենք պահպանում ենք փոփոխականի մեջ այն, ինչ սերվերը պատասխանել է հարցմանը, հաջորդ քայլում մենք ստուգում ենք, որ կարգավիճակը UP է և, եթե դա այդպես չէ, ապա մենք դուրս ենք գալիս սխալմամբ: Եթե Ձեզ անհրաժեշտ է ձեռքերով «ծանրաբեռնել» գործողությունը, ապա ելք 1-ից - հարմար զենք.
- name: send alert in telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Health check of the:
${{secrets.SERVER_HOST}}/api/actuator/health
failed with the result:
${{ steps.ping.outputs.status }}
Մենք հեռագրում ենք ուղարկում միայն այն դեպքում, եթե գործողությունը ձախողվել է նախորդ քայլում: Հաղորդագրություն ուղարկելու համար մենք օգտագործում ենք appleboy/telegram-action; դուք կարող եք կարդալ այն մասին, թե ինչպես ստանալ բոտի նշան և չաթի ID փաստաթղթերում.
Մի մոռացեք գրել Github-ի գաղտնիքներում՝ URL սերվերի համար և ժետոններ հեռագրային բոտի համար:
Բոնուսային ուղու՝ JIRA ծույլերի համար
Ես խոստացել էի, որ կվերադառնանք JIRA, և մենք վերադարձել ենք։ Հարյուրավոր անգամներ ես տեսել եմ մի իրավիճակ stand-up-ներում, երբ մշակողները ստեղծել են գործառույթ, միավորել մասնաճյուղը, բայց մոռացել են խնդիրը քաշել JIRA-ի մեջ: Իհարկե, եթե այս ամենն արվեր մեկ տեղում, ավելի հեշտ կլիներ, բայց իրականում մենք գրում ենք կոդը IDE-ում, ճյուղերը միավորում bitbucket-ի կամ GitHub-ի մեջ, այնուհետև առաջադրանքները քաշում ենք Jira-ի մեջ, դրա համար պետք է բացել նոր պատուհաններ: , երբեմն նորից մուտք գործեք և այլն: Երբ դուք հիանալի հիշում եք, թե ինչ պետք է անեք հետո, ապա իմաստ չկա նորից բացել տախտակը: Արդյունքում, առավոտյան կանգառում դուք պետք է ժամանակ հատկացնեք առաջադրանքների տախտակի թարմացմանը:
GitHub-ը նաև կօգնի մեզ այս սովորական առաջադրանքում. սկզբի համար մենք կարող ենք խնդիրները ինքնաբերաբար քաշել code_review սյունակ, երբ մենք դիմում ենք քաշելու հարցում: Ձեզ անհրաժեշտ է միայն հետևել մասնաճյուղի անվանման կոնվենցիային.
[имя проекта]-[номер таска]-название
օրինակ, եթե նախագծի բանալին «GitHub Actions» GA է, ապա GA-8-jira-bot կարող է լինել ԳԱ-8 առաջադրանքի իրականացման ճյուղ։
JIRA-ի հետ ինտեգրումն աշխատում է Atlassian-ի գործողությունների միջոցով, դրանք կատարյալ չեն, պետք է ասեմ, որ դրանցից մի քանիսն ինձ մոտ ընդհանրապես չեն աշխատել: Բայց մենք կքննարկենք միայն նրանց, որոնք անպայման աշխատում են և ակտիվորեն օգտագործվում են։
Նախ անհրաժեշտ է մուտք գործել JIRA՝ օգտագործելով գործողությունը՝ atlassian/gajira-login
jobs:
build:
runs-on: ubuntu-latest
name: Jira Workflow
steps:
- name: Login
uses: atlassian/gajira-login@master
env:
JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
Դա անելու համար դուք պետք է ստանաք նշան JIRA-ում, թե ինչպես դա անել, նկարագրված է այստեղ.
Մենք հանում ենք առաջադրանքի նույնացուցիչը մասնաճյուղի անունից.
- name: Find Issue
id: find_issue
shell: bash
run: |
echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo brach name: $GITHUB_HEAD_REF
echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- name: Check Issue
shell: bash
run: |
if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
exit 1
fi
echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
Եթե որոնեք GitHub շուկայում, կարող եք գտնել գործողություն այս առաջադրանքի համար, բայց ես ստիպված էի նույն բանը գրել grep-ի միջոցով՝ օգտագործելով մասնաճյուղի անունը, քանի որ Atlassian-ի այս գործողությունը ոչ մի կերպ չէր ուզում աշխատել իմ նախագծի վրա: , պարզելու համար, թե ինչն էր այնտեղ սխալ, ավելի երկար, քան նույն բանը ձեր ձեռքերով անելը:
Մնում է միայն առաջադրանքը տեղափոխել «Կոդերի վերանայում» սյունակ՝ ձգման հարցում ստեղծելիս.
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Դրա համար հատուկ գործողություն կա GitHub-ում, դրա կարիքը միայն նախորդ քայլում ձեռք բերված հարցի ID-ն է և JIRA-ի թույլտվությունը, որը մենք արել ենք վերևում:
Նույն կերպ, դուք կարող եք քաշել առաջադրանքները, երբ միաձուլվում եք հիմնականին, և այլ իրադարձություններ GitHub աշխատանքային հոսքից: Ընդհանուր առմամբ, ամեն ինչ կախված է ձեր երևակայությունից և սովորական գործընթացները ավտոմատացնելու ցանկությունից:
Արդյունքները
Եթե դուք նայեք դասական DEVOPS դիագրամին, մենք ծածկել ենք բոլոր փուլերը, բացառությամբ, հնարավոր է, գործելու, կարծում եմ, եթե փորձեք, կարող եք գտնել որոշակի գործողություններ շուկայում՝ Help-desk համակարգի հետ ինտեգրվելու համար, այնպես որ մենք կենթադրենք, որ խողովակաշարը շրջվել է: պետք է լինի մանրակրկիտ, և դրա օգտագործման հիման վրա կարելի է եզրակացություններ անել:
Կոալիցիայում:
- Շուկա բոլոր առիթների համար պատրաստի ակցիաներով, սա շատ թույն է։ Դրանցից շատերում կարող եք նաև նայել սկզբնաղբյուրը՝ հասկանալու համար, թե ինչպես լուծել նմանատիպ խնդիր կամ հեղինակին ուղարկել գործառույթի հարցում անմիջապես GitHub-ի պահոցում:
- Հավաքման նպատակային հարթակի ընտրությունը՝ Linux, mac os, windows, բավականին հետաքրքիր հատկություն է:
- Github Փաթեթները հիանալի բան են, հարմար է ամբողջ ենթակառուցվածքը մեկ տեղում պահել, պետք չէ ճամփորդել տարբեր պատուհաններով, ամեն ինչ գտնվում է մկնիկի մեկ կամ երկու կտտոցների շառավղով և հիանալի ինտեգրված է GitHub Actions-ի հետ: Docker ռեեստրի աջակցությունը անվճար տարբերակում նույնպես լավ առավելություն է:
- GitHub-ը թաքցնում է գաղտնիքները շինարարական տեղեկամատյաններում, ուստի այն օգտագործելը գաղտնաբառեր և նշաններ պահելու համար այնքան էլ սարսափելի չէ: Իմ բոլոր փորձերի ընթացքում ես երբեք չկարողացա գաղտնիքը տեսնել իր մաքուր տեսքով վահանակում:
- Անվճար բաց կոդով նախագծերի համար
Դեմ:
- YML, լավ, ես նրան չեմ սիրում: Նման հոսքի հետ աշխատելիս ամենատարածված commit հաղորդագրությունը, որը ես ունեմ, «fix yml format»-ն է, երբեմն մոռանում ես ինչ-որ տեղ ներդիր դնել, երբեմն սխալ տողում ես գրում: Ընդհանրապես, անկյունաչափով և քանոնով էկրանի առաջ նստելը ամենահաճելի փորձը չէ։
- DEBUG-ը, հոսքի վրիպազերծումը commit-ներով, վերակառուցում գործարկելը և կոնսոլից դուրս գալը միշտ չէ, որ հարմար է, բայց դա ավելի շատ «դուք չափն անցել եք» կատեգորիային է պատկանում. դուք սովոր եք աշխատել հարմար IDEA-ի հետ, երբ կարող եք վրիպազերծել որևէ բան: .
- Դուք կարող եք գրել ձեր գործողությունը ցանկացած բանի վրա, եթե այն փաթաթեք Docker-ով, բայց միայն javascript-ն է աջակցում բնիկ, իհարկե սա ճաշակի հարց է, բայց ես կնախընտրեի այլ բան js-ի փոխարեն:
Հիշեցնեմ, որ պահոցը բոլոր սցենարներով այստեղ է.
Հաջորդ շաբաթ ես ելույթ կունենամ հետ Heisenbug 2020 Piter կոնֆերանսում: Ես ձեզ կասեմ ոչ միայն, թե ինչպես խուսափել սխալներից՝ թեստային տվյալները պատրաստելիս, այլև կիսվել Java հավելվածներում տվյալների հավաքածուների հետ աշխատելու իմ գաղտնիքներով:
Source: www.habr.com