Më ndodh shpesh të ndërtoj një pipeline për ndërtimin e projekteve në Java. Ndonjëherë janë open-source, ndonjëherë jo. Së fundmi, vendosa të provoj të transferoj disa nga depot e mia nga Travis-CI dhe TeamCity në GitHub Actions, dhe kjo është ajo që arrita.
ĂfarĂ« do tĂ« automatizojmĂ«
Për të filluar, na nevojitet një projekt që do të automatizojmë, le të krijojmë një aplikacion të vogël në Spring Boot / Java 11 / Maven. Në këtë artikull, logjika e aplikacionit nuk na intereson fare, na intereson infrastruktura përreth aplikacionit, kështu që na mjafton një kontrollues i thjeshtë REST API.
Mund ta shihni kodin burimor këtu: të gjitha etapet e ndërtimit të pipeline-it janë pasqyruar në pull requests të këtij projekti.
JIRA dhe planifikimi
Duhet thënë se zakonisht përdorim JIRA si një ndjekës të detyrave, kështu që le të krijojmë një bord të veçantë për këtë projekt dhe të hedhim aty detyrat e para:
Pak më vonë do të kthehemi te ajo që mund të ofrojë në lidhje JIRA dhe GitHub.
Automatizojmë ndërtimin e projektit
Projekti ynë testues ndërttohet përmes maven, kështu që ndërtimi i tij është mjaft i thjeshtë, e gjithë çfarë na nevojitet është mvn clean package.
PĂ«r ta bĂ«rĂ« kĂ«tĂ« me ndihmĂ«n e GitHub Actions, na nevojitet tĂ« krijojmĂ« nĂ« repository njĂ« skedĂ« me pĂ«rshkrimin e workflow-t tonĂ«, kjo mund tĂ« bĂ«het me njĂ« skedĂ« tĂ« zakonshme yml, nuk mund tĂ« them se mĂ« pĂ«lqen «programimi nĂ« yml», por çfarĂ« tĂ« bĂ«jmĂ« â krijojmĂ« nĂ« direktorinĂ« .github/workflow/ skedĂ«n build.yml nĂ« tĂ« cilĂ«n do tĂ« pĂ«rshkruajmĂ« veprimet gjatĂ« ndĂ«rtimit tĂ« degĂ«s master:
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
nĂ« â kjo Ă«shtĂ« pĂ«rshkrimi i ngjarjes qĂ« do tĂ« aktivizojĂ« skriptin tonĂ«.
on: pull_request / push â tregon se ky workflow duhet tĂ« aktivizohet nĂ« çdo push nĂ« master dhe krijimin e pull requests.
Më pas shkon përshkrimi i detyrave (jobs) dhe hapat e ekzekutimit (steps) për secilën detyrë.
runs-on â kĂ«tu mund tĂ« zgjedhim sistemin operativ tĂ« destinacionit, me befasinĂ« mund tĂ« zgjidhni edhe Mac OS, por nĂ« repository private, kjo Ă«shtĂ« njĂ« kĂ«naqĂ«si mjaft e kushtueshme (nĂ« krahasim me linux).
uses lejon ri-përdorimin e veprimeve të tjera, kështu që, për shembull, me anë të veprimit actions/setup-java ne instalojmë ambientin për Java 11.
With the help of with Ne mund të përcaktojmë parametrat me të cilat aktivizojmë veprimin, në thelb, këto janë argumentet që do të kalohen në aksion.
Tani mbetet vetëm të përfundojmë ndërtimin e projektit me Maven: run: mvn -B clean package --all -B tregon që na nevojitet modu i mos-interaksionit, për të mos lejuar që Maven të kërkojë ndonjëherë diçka prej nesh
Fantastike! Tani, me çdo commit në master, ndërtohet projekti.
Automatizojmë nisjen e testeve
NdĂ«rtimi Ă«shtĂ« i mirĂ«, por nĂ« realitet projekti mund tĂ« ndĂ«rtohet pa problem, por tĂ« mos funksionojĂ«. Prandaj, hapi vijues Ă«shtĂ« automatizimi i ekzekutimit tĂ« testeve. PĂ«r mĂ« tepĂ«r, Ă«shtĂ« shumĂ« e dobishme tĂ« shikosh rezultatin e kalimit tĂ« testeve kur bĂ«n rishikimin e PR â e di me siguri qĂ« testet kalojnĂ« dhe askush nuk ka harruar tĂ« ekzekutojĂ« degĂ«n e tij para se tĂ« bĂ«jĂ« merge.
Bëjmë nisjen e testeve gjatë krijimit të pull-request-it dhe merge në master, dhe po ashtu do të shtojmë ndërtimin e raportit mbi mbulimin e kodit.
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 }}
Për mbulimin e testeve përdor codecov në kombinim me plugjin jacoco. Codecov ka veprimin e tij, por për të punuar me pull-request-in tonë, i nevojitet një token:
${{ secrets.CODECOV_TOKEN }} â njĂ« konstrukt tĂ« tillĂ« do ta takojmĂ« edhe disa herĂ«, secrets Ă«shtĂ« mekanizmi i ruajtjes sĂ« sekreteve nĂ« GitHub, ku mund tĂ« pĂ«rshkruajmĂ« fjalĂ«kalime/tokenĂ«/hoste/URL dhe tĂ« dhĂ«na tĂ« tjera qĂ« nuk duhet tĂ« shfaqen nĂ« kodin burim.
Të shtosh një variabël në secrets, mund të bëhet në cilësimet e depozitës në GitHub:
Mund tĂ« marrĂ«sh tokenin nĂ« pas autorizimit pĂ«rmes GitHub, pĂ«r tĂ« shtuar njĂ« projekt publik, thjesht duhet tĂ« ndjekĂ«sh njĂ« lidhje tĂ« kĂ«tij lloji: /[repo name]. ĐŃĐžĐČĐ°ŃĐœŃĐč ŃĐ”ĐżĐŸĐ·ĐžŃĐŸŃĐžĐč ŃĐŸĐ¶Đ” ĐŒĐŸĐ¶ĐœĐŸ ĐŽĐŸĐ±Đ°ĐČĐžŃŃ, ĐŽĐ»Ń ŃŃĐŸĐłĐŸ ĐœĐ°ĐŽĐŸ ĐŽĐ°ŃŃ ĐżŃĐ°ĐČĐ° codecov ĐżŃĐžĐ»ĐŸĐ¶Đ”ĐœĐžŃ ĐČ ĐłĐžŃŃ Đ°Đ±Đ”.
Shtojmë plugjin jacoco në skedarin POM:
org.jacoco
jacoco-maven-plugin
0.8.4
prepare-agent
report
test
report
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
plain
**/*Test*.java
**/*IT*.java
Tani tani çdo pull request do të hyjë boti codecov dhe do të shtojë grafikun e ndryshimit të mbulimit:
Të shtojmë një analizues statik
Në shumicën e projekteve të mia open source unë përdor sonar cloud për analizën statike të kodit, është mjaft e lehtë të lidhet me travis-ci. Pra, ky është një hap logjik gjatë migrimit në GitHub Actions, të bëjmë të njëjtën gjë. Marketingu i veprimeve është një gjë e shkëlqyer, por këtë herë ai më ka lënë pak në baltë, sepse për zakon kam gjetur veprimin e nevojshëm dhe e kam shkruar atë në workflow. Doli se sonar nuk mbështet funksionimin përmes veprimit për analizimin e projekteve në maven ose gradle. Kjo është shpjeguar natyrisht në dokumentacion, por kush e lexon atë?!
Përmes veprimit nuk është e mundur, kështu që do ta bëjmë përmes mvn plugin:
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 â mund tĂ« merret nĂ« dhe duhet tĂ« shkruhet nĂ« secrets. GITHUB_TOKEN â Ă«shtĂ« njĂ« token i integruar, i cili gjenerohet nga GitHub, me tĂ« cilin sonarcloud[bot] do tĂ« mund tĂ« autentikohet nĂ« git, pĂ«r tĂ« lĂ«nĂ« komente nĂ« pull requestet.
Dsonar.projectKey â emri i projektit nĂ« sonar, mund tĂ« shikohet nĂ« cilĂ«simet e projektit.
Dsonar.organization â emri i organizatĂ«s nga GitHub.
Bëmë një pull request dhe presim, kur sonarcloud[bot] të vijë me komente:
Menaxhimi i lëshimeve
Ndërtimin e kemi konfiguruar, testet i kemi kryer, tani mund të bëjmë një lëshim. Le të shohim se si GitHub Actions ndihmon shumë në thjeshtimin e menaxhimit të lëshimeve.
NĂ« punĂ« kam projekte, baza e kodit tĂ« cilĂ«ve ndodhet nĂ« bitbucket (siç thotĂ« historia «nĂ« ditĂ« shkruaj nĂ« bitbucket, nĂ« natĂ« komitoj nĂ« GitHub»). FatkeqĂ«sisht, bitbucket nuk ka mjete tĂ« ndĂ«rtuara pĂ«r menaxhimin e lĂ«shimeve. Kjo Ă«shtĂ« njĂ« problem, sepse pĂ«r çdo lĂ«shim duhet tĂ« krijohet manualisht njĂ« faqe nĂ« confluence dhe tĂ« derdhen atje tĂ« gjitha karakteristikat qĂ« janĂ« pĂ«rfshirĂ« nĂ« lĂ«shim, tĂ« rishikohet tĂ«rĂ« mendja, detyrat nĂ« jira, komitet nĂ« depo. Ka shumĂ« shanse pĂ«r gabime, mund tĂ« harrohet diçka ose tĂ« shkruhet ajo qĂ« Ă«shtĂ« lĂ«shuar mĂ« herĂ«t, ndonjĂ«herĂ« Ă«shtĂ« thjesht e paqartĂ« se çfarĂ« duhet t'i atribuohesh njĂ« pull-request-i â Ă«shtĂ« njĂ« karakteristikĂ« apo njĂ« rregullim gabimesh, ose njĂ« rregullim testesh, ose diçka infrastrukturore.
Si mund tĂ« na ndihmojĂ« GitHub actions? Ka njĂ« ekzekutues tĂ« shkĂ«lqyer â release drafter, ai lejon tĂ« pĂ«rcaktohet njĂ« shabllon i skedarit release notes, nĂ« mĂ«nyrĂ« qĂ« tĂ« konfigurohen kategoritĂ« e pull-request-eve dhe t'i grupojĂ« automatikisht ato nĂ« skedarin release notes:
Shembuj i shabllonit për konfigurimin e raportit (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Karakteristika të Reja'
labels:
- 'type:features'
# në këtë kategori mbledhim të gjitha PR me etiketën type:features
- title: ' Rregullime Gabimesh'
labels:
- 'type:fix'
# njësoj për etiketën type:fix etj.
- title: ' Dokumentacion'
labels:
- 'type:documentation'
- title: ' Konfigurim'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Ndryshimet
$CHANGES
Shtojmë skriptin për gjenerimin e një skice të lëshimit (.github/workflows/release-draft.yml):
name: "Krijo skicën e lëshimit"
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 }}
TĂ« gjitha pull-request-et nga ky moment do tĂ« grumbullohen automatikisht nĂ« release notes â magji!
KĂ«tu mund tĂ« lindĂ« pyetja: çfarĂ« nĂ«se zhvilluesit harrojnĂ« tĂ« vendosin etiketat nĂ« PR? AtĂ«herĂ« Ă«shtĂ« e paqartĂ«, nĂ« cilĂ«n kategori i pĂ«rket, dhe pĂ«rsĂ«ri do tĂ« duhet tĂ« merremi me secilin PR veç e veç. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, mund tĂ« pĂ«rdorim njĂ« tjetĂ«r ekzekutues â label verifier â ai kontrollon prani e etiketimeve nĂ« pull-request. NĂ«se nuk ka asnjĂ« etiketĂ« tĂ« detyrueshme, atĂ«herĂ« verifikimi do tĂ« dĂ«shtojĂ« dhe ne do ta shohim kĂ«tĂ« mesazh nĂ« pull-request-in tonĂ«.
name: "Verifiko etiketat e tipit"
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'
Tani çdo pull-request duhet të etiketohet me një nga etiketat: type:fix, type:features, type:documentation, type:tests, type:config.
Auto-anotimi i kërkesave për tërheqje
Pasi që përmendëm një temë si puna efektive me kërkesat për tërheqje, duhet të flasim edhe për një veprim si labeler, i cili vendos etiketa në PR në bazë të dosjeve që janë ndryshuar. Për shembull, mund ta marksim si [build] çdo kërkesë për tërheqje që ka ndryshime në katalogun .github/workflow.
Të lidhësh këtë është mjaft e thjeshtë:
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 }}
Na nevojitet gjithashtu një file për përshkrimin e përputhshmërisë së katalogjeve të projektit me temat e kërkesave për tërheqje:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nuk arrita të bashkoj veprimin që automatikisht vendos etiketa në kërkesat për tërheqje me veprimin që kontrollon praninë e etiketeve obligative, match-label nuk do të pranojë etiketat e vendosura nga boti. Duket se është më e lehtë të shkruash veprimin tënd, që bashkon të dy fazat. Por edhe në këtë formë, është mjaft e lehtë të përdoret, duhet të zgjidhni një etiketë nga lista kur krijoni kërkesën për tërheqje.
ĂshtĂ« koha pĂ«r tĂ« bĂ«rĂ« deploy
Kam provuar disa variante për deploy përmes GitHub Actions (nëpërmjet ssh, nëpërmjet scp, dhe me docker-hub), dhe mund të them se, me sa duket, do të gjeni një mënyrë për të ngarkuar binarin në server, pavarësisht se sa i komplikuar është pipeline juaj.
Më pëlqeu varianti që mbante gjithë infrastrukturën në një vend, prandaj le të shohim se si të bëjmë deploy në GitHub Packages (ky është një depo për përmbajtje binare, npm, jar, docker).
Skirp tim i ndërtimit të imazhit docker dhe publikimit të tij në GitHub Packages:
emri: Nxjerr imazhin docker
në:
shtyp:
degët:
- 'master'
punët:
ndërtim_imazhi_docker:
funksionon në: ubuntu-18.04
hapa:
# Ndërto JAR:
- përdor: actions/checkout@v1
- emri: caktoni JDK 11
përdor: actions/setup-java@v1
me:
java-version: 1.11
- emri: Paketa Maven
ekzekuto: mvn -B clean compile package -DskipTests
# Caktoni variabla globale mjedisi:
- emri: caktoni env global
id: global_env
ekzekuto: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*\/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com\/${GITHUB_REPOSITORY}\/${GITHUB_REPOSITORY#*\/}"
# Ndërtoni imazhin Docker:
- emri: Ndërto dhe etiketoni imazhin
ekzekuto: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- emri: Konektimi në Docker
ekzekuto: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publikoni imazhin në repositorin e paketave në github:
- emri: Publiko imazhin
env:
IMAGE_NAME: $GITHUB_REPOSITORY
ekzekuto: docker push "docker.pkg.github.com\/$GITHUB_REPOSITORY\/${{ steps.global_env.outputs.IMAGE_NAME }}"
Për të filluar, na duhet të ndërtojmë skedarin JAR të aplikacionit tonë, pas së cilës llogaritëm rrugën për regjistrin Docker të GitHub dhe emrin e imazhit tonë. Këtu ka disa figura që nuk i kemi hasur më parë:
- Struktura e formatit: echo «::set-output name=NAME::VALUE» lejon caktimin e një vlerë varianti në hapin aktual, në mënyrë që të mund të lexohet më vonë në të gjithë hapat e tjerë.
- Për të marrë vlerën e variantit të caktuar në hapin e mëparshëm mund të përdorim identifikuesin e këtij hapi: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Në ndryshoren standarde GITHUB_REPOSITORY ruhen emri i repositorit dhe pronari («owner/repo-name»). Për të nxjerrë nga kjo varg gjithçka përveç emrit të repositorit, do të përdorim sintaksën bash: ${GITHUB_REPOSITORY#*\/}
Më pas, duhet të ndërtojmë imazhin docker:
docker build -t "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions:latest"
Identifikohuni në regjistër:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Dhe publikoni imazhin në Repositorin e Paketave në GitHub:
docker push "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions"
PĂ«r tĂ« caktuar versionin e imazhit, ne pĂ«rdorim shifrat e para nga SHA-hashi i commit-it â GITHUB_SHA kĂ«tu gjithashtu ka nuanca, nĂ«se do tĂ« bĂ«ni kĂ«to ndĂ«rtime jo vetĂ«m gjatĂ« bashkimit nĂ« master, por edhe pĂ«r ngjarjen e krijimit tĂ« njĂ« kĂ«rkese pĂ«r bashkim, atĂ«herĂ« SHA mund tĂ« mos pĂ«rputhet me hash-in qĂ« ne shohim nĂ« historinĂ« e git-it, sepse veprimi actions/checkout krijon njĂ« hash unik, pĂ«r tĂ« shmangur bllokimin e ndĂ«rsjellĂ« tĂ« veprimeve nĂ« PR.
Nëse gjithçka ka shkuar për mrekulli, atëherë duke hapur seksionin e paketave (https://github.com/antkorwin/github-actions/packages) në repositor, do të shihni një imazh të ri docker:
At the same place, you can view the list of Docker image versions.
All that's left is to configure our server to work with this registry and restart the service. I'll probably explain how to do this with systemd another time.
Monitorimi
Let's look at a simple way to perform a health check of our application using GitHub Actions. Our boot application has an actuator, so there's no need to write an API for checking its status; everything is already done for the lazy ones. You just need to hit the host: 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"}
All we need to do is to write a cron task to check the server, and if it doesn't respond, we will send a notification to Telegram.
First, let's figure out how to run the workflow on a cron schedule:
on:
schedule:
- cron: '*/5 * * * *'
It's simple, I can't believe that such events can be created in GitHub, which don't fit into webhooks at all. The details are in the documentation:
We'll check the server status manually using 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 failed"
exit 1
fi
echo "It's OK"
First, we save the response from the server to a variable, then in the next step, we check that the status is UP and, if not, we exit with an error. If you need to manually 'fail' the action, then exit 1 â is a suitable instrument.
- 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 }}
We send the notification to Telegram only if the action failed in the previous step. To send a message, we use appleboy/telegram-action; you can read in the documentation how to obtain the bot token and chat ID:
Do not forget to specify in the GitHub secrets: the server URL and the tokens for the Telegram bot.
Bonus track â JIRA for the lazy
I promised that we would return to JIRA, and we did. I have seen hundreds of times in stand-ups the situation where developers have implemented a feature, merged a branch, but forgot to move the task in JIRA. Of course, if all this were done in one place, it would be easier, but in fact, we write code in an IDE, merge branches in Bitbucket or GitHub, and then move tasks in Jira, which requires opening new windows, sometimes logging in again, etc. When you clearly remember what needs to be done next, thereâs no point in opening the board again. As a result, in the morning during the stand-up, we need to spend time updating the task board.
GitHub will help us with this routine task as well; to start, we can automatically move tasks to the code_review column when we submit a pull request. All that is needed is to adhere to the branch naming convention:
[project_name]-[task_number]-title
for example, if the project key "GitHub Actions" is GA, then GA-8-jira-bot could be a branch for implementing task GA-8.
The integration with JIRA works through actions from Atlassian; they are not perfect, and I must say that some of them have not worked for me at all. But we will discuss only those that definitely work and are actively used.
To begin with, you need to authorize in JIRA using the action: 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 }}
For this, you need to obtain a token in JIRA; how to do this is described here:
We extract the task identifier from the branch name:
- 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 branch 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 successfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
If you search in the GitHub marketplace, you can find an action for this task, but I had to write the same thing using grep on the branch name because that action from Atlassian did not want to work on my project; figuring out what was wrong took longer than doing the same manually.
Nuk duhet vetëm të transferoni detyrën në kolonën "Code review" kur krijoni pull request-in:
- emri: Kalimi i detyrës
nëse: ${{ sukses() }}
përdor: atlassian/gajira-transition@master
me:
detyra: ${{ hapat.gjej_detyrën.daljet.ISSUE_ID }}
kalimi: "Code review"
Për këtë ka një veprim të veçantë në GitHub, gjithçka që i nevojitet është identifikuesi i detyrës, i marrë në hapin e mëparshëm, dhe autorizimi në JIRA, që e bëmë më lart.
Po ashtu, mund të tërhiqni detyrat gjatë merge në master dhe ngjarjeve të tjera nga GitHub workflow. Në përgjithësi, gjithçka varet nga imagjinata juaj dhe dëshira për të automatizuar proceset e zakonshme.
PĂ«rfundimet
Nëse shikoni diagramin klasik të DEVOPS, duhet ta kemi mbuluar të gjitha fazat, përveç operate, mendoj se nëse përpiqemi, mund të gjejmë ndonjë aksion në treg për integrimin me sistemin e ndihmës, kështu që le të mendojmë se pipeline doli mjaft i mirë dhe në bazë të përdorimit të tij mund të nxirren përfundime.
Avantazhet:
- Marketplace me veprimet e gatshme për çdo rast është shumë e shkëlqyer. Në shumicën e tyre, madje mund të shihni burimin, për të kuptuar se si të zgjidhni një detyrë të ngjashme ose të postoni një kërkesë për veçori tek autori direkt në depozitën e GitHub.
- Zgjedhja e platformës së synuar për ndërtim: Linux, macOS, Windows është një veçori mjaft interesante.
- GitHub Packages Ă«shtĂ« njĂ« gjĂ« e shkĂ«lqyer, mbajtja e tĂ« gjithĂ« infrastrukturĂ«s nĂ« njĂ« vend Ă«shtĂ« e pĂ«rshtatshme, nuk Ă«shtĂ« nevoja tĂ« shfletosh nĂ«pĂ«r okĂ« tĂ« ndryshme, gjithçka Ă«shtĂ« brenda njĂ« apo dy klikimeve dhe Ă«shtĂ« perfekt e integruar me GitHub Actions. MbĂ«shtetje pĂ«r docker registry nĂ« versionin falas â kjo Ă«shtĂ« njĂ« avantazh i mirĂ«.
- GitHub fsheh sekrety në log-ët e ndërtimit, prandaj përdorimi i tij për mbajtjen e fjalëkalimeve dhe tokenëve nuk është aq i frikshëm. Gjatë të gjithë eksperimenteve të mia nuk kam arritur asnjëherë të shoh sekretin në mënyrë të pastër në konsolë.
- Falë për projektet Open Source
Disavantazhet:
- YML, nuk e pëlqej. Kur punoj me një flow të tillë, mesazhi im më i shpeshtë i commit-it është "riparo formatin yml", atëherë harrohet të vendosësh ndonjë tab, atëherë shkruhet në rreshtin e gabuar. Në përgjithësi, të qëndrosh përpara ekranit me tjetër ndihmues dhe linjën nuk është një aktivitet i këndshëm.
- DEBUG, debugimi i flow me commit-e, nisjen e ri ndërtimit dhe output-in në konsolë nuk është gjithmonë i përshtatshëm, por kjo është më shumë në kategorinë "ju jeni tepruar", jeni mësuar të punoni me IDEA të përshtatshme, kur mund të debugoni gjithçka.
- Mund ta shkruash një aksion mbi çfarëdo nëse e mbështjell në Docker, por natyrshëm mbështetet vetëm JavaScript; sigurisht, është një çështje shije, por do të preferoja diçka tjetër në vend të JS.
Më kujto, se depoja me të gjithë skriptet është këtu:
Javën e ardhshme do të flas në konferencën Heisenbug 2020 Piter. Do të flas jo vetëm për mënyrën se si të shmangim gabimet gjatë përgatitjes së të dhënave testuese, por gjithashtu do të ndaj sekretet e mia për punën me grupe të dhënash në aplikacionet Java!
Burimi: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish