Shpesh më duhet të ndërtoj një tubacion për ndërtimin e projekteve në Java. Ndonjëherë është me burim të hapur, ndonjëherë jo. Kohët e fundit vendosa të provoj të zhvendos disa nga depot e mia nga Travis-CI dhe TeamCity në GitHub Actions, dhe kjo është ajo që doli prej saj.
Çfarë do të automatizojmë?
Së pari, na duhet një projekt që do ta automatizojmë, le të bëjmë një aplikacion të vogël në Spring boot / Java 11 / Maven. Për qëllimet e këtij artikulli, ne nuk do të na interesojë fare logjika e aplikacionit; infrastruktura rreth aplikacionit është e rëndësishme për ne, kështu që një kontrollues i thjeshtë REST API do të na mjaftojë.
Burimet mund t'i shikoni këtu: Të gjitha fazat e ndërtimit të një tubacioni pasqyrohen në kërkesat për tërheqje për këtë projekt.
JIRA dhe planifikimi
Vlen të thuhet se ne zakonisht përdorim JIRA si një gjurmues çështjesh, kështu që le të krijojmë një bord të veçantë për këtë projekt dhe të shtojmë çështjet e para atje:
Pak më vonë do të kthehemi tek gjërat interesante që JIRA dhe GitHub mund të ofrojnë në kombinim.
Ne automatizojmë montimin e projektit
Projekti ynë i testimit është ndërtuar nëpërmjet maven, kështu që ndërtimi i tij është mjaft i thjeshtë, gjithçka që na nevojitet është paketa mvn e pastër.
Për ta bërë këtë duke përdorur Github Actions, do të duhet të krijojmë një skedar në depo që përshkruan rrjedhën tonë të punës, kjo mund të bëhet me një skedar të rregullt yml, nuk mund të them se më pëlqen "programimi yml", por çfarë mund të bëjmë - ne e bëjmë atë në .github/ directory workflow/ file build.yml në të cilën do të përshkruajmë veprimet kur ndërtojmë degën kryesore:
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 — ky është një përshkrim i ngjarjes në të cilën do të lansohet skenari ynë.
në: pull_request/push — tregon se kjo rrjedhë pune duhet të nisë sa herë që i bëhet një shtytje masterit dhe krijohen kërkesa për tërheqje.
Më poshtë është një përshkrim i detyrave (Punë) dhe hapat e ekzekutimit (Hapat) për çdo detyrë.
vrapon-on - këtu mund të zgjedhim OS-në e synuar, çuditërisht, mund të zgjidhni edhe Mac OS, por në depo private kjo është mjaft e shtrenjtë (krahasuar me Linux).
përdor ju lejon të ripërdorni veprime të tjera, për shembull, duke përdorur veprimet/setup-java që instalojmë mjedisin për Java 11.
Me anë të me ne mund të specifikojmë parametrat me të cilët nisim veprimin; në thelb, këto janë argumentet që do t'i kalojnë veprimit.
Gjithçka që mbetet është të ekzekutoni ndërtimin e projektit me Maven: run: mvn -B clean package flamur -B thotë se ne kemi nevojë për një mënyrë jo-interaktive, në mënyrë që maven papritmas të mos dëshirojë të na pyesë diçka
E shkëlqyeshme! Tani, sa herë që i angazhoheni masterit, fillon ndërtimi i projektit.
Automatizimi i nisjeve të testit
Asambleja është e mirë, por në realitet, një projekt mund të montohet në mënyrë të sigurt, por jo të funksionojë. Prandaj, hapi tjetër është automatizimi i testeve. Për më tepër, është mjaft e përshtatshme të shikoni rezultatet e kalimit të testeve kur bëni një rishikim të PR - e dini me siguri që testet kalojnë dhe askush nuk harroi të drejtonte degën e tij përpara se të bëni një bashkim.
Ne do të kryejmë teste kur krijojmë një kërkesë tërheqëse dhe do të bashkojmë në master, dhe në të njëjtën kohë do të shtojmë krijimin e një raporti 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 të mbuluar testet, unë përdor codecov në lidhje me shtojcën jacoco. codecov ka veprimin e vet, por i duhet një shenjë për të punuar me kërkesën tonë për tërheqje:
${{ secrets.CODECOV_TOKEN }} — do ta shohim këtë ndërtim më shumë se një herë, sekretet janë një mekanizëm për ruajtjen e sekreteve në GitHub, mund të shkruajmë atje fjalëkalime/tokena/host/url dhe të dhëna të tjera që nuk duhet të përfshihen në bazën e kodit të depove.
Ju mund të shtoni një ndryshore në sekretet në cilësimet e depove në GitHub:
Ju mund të merrni një shenjë në Pas autorizimit nëpërmjet GitHub, për të shtuar një projekt publik, mjafton të ndiqni një lidhje si kjo: /[emri repo]. Mund të shtohet gjithashtu një depo private; për ta bërë këtë, duhet t'i jepni të drejtat e kodicov aplikacionit në Github.
Shtoni shtojcën jacoco në skedarin 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>
Tani roboti codecov do të hyjë në secilën nga kërkesat tona për tërheqje dhe do të shtojë një grafik ndryshimi të mbulimit:
Le të shtojmë një analizues statik
Në shumicën e projekteve të mia me burim të hapur, unë përdor renë sonar për analizën e kodit statik, është mjaft e lehtë të lidhesh me travis-ci. Pra, është një hap logjik kur migroni në GitHub Actions për të bërë të njëjtën gjë. Tregu i aksionit është një gjë e lezetshme, por këtë herë më zhgënjeu pak, sepse nga zakoni gjeta veprimin që më duhej dhe e shtova në rrjedhën e punës. Por doli që hidrolokatori nuk e mbështet punën përmes një aksioni për analizimin e projekteve në maven ose gradle. Sigurisht që kjo është shkruar në dokumentacion, por kush e lexon?!
Nuk është e mundur përmes një veprimi, kështu që ne do ta bëjmë atë përmes shtojcës 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 - mund të merret në dhe ju duhet ta regjistroni atë në fshehtësi. GITHUB_TOKEN - ky është një token i integruar që gjeneron GitHub, me ndihmën e të cilit sonarcloud[bot] do të mund të identifikohet në Git për të na lënë mesazhe në kërkesat për tërheqje.
Dsonar.projektKey — emrin e projektit në sonar, mund ta shihni në cilësimet e projektit.
Dsonar.organizata — emri i organizatës nga GitHub.
Ne bëjmë një kërkesë për tërheqje dhe presim që sonarcloud[bot] të vijë në komente:
Menaxhimi i lëshimit
Ndërtimi është konfiguruar, testet janë kryer dhe ne mund të bëjmë një lëshim. Le të shohim se si Veprimet e GitHub mund ta bëjnë menaxhimin e lëshimit shumë më të lehtë.
Në punë, kam projekte, baza e kodit të të cilave është në bitbucket (gjithçka është si në atë histori "Unë shkruaj në bitbucket gjatë ditës, angazhohem në GitHub gjatë natës"). Fatkeqësisht, bitbucket nuk ka mjete të integruara të menaxhimit të lëshimit. Ky është një problem, sepse për çdo lëshim ju duhet të krijoni manualisht një faqe në konfluencë dhe të hidhni atje të gjitha veçoritë e përfshira në publikim, të kërkoni nëpër pallatet e mendjes, detyrat në jira, kryerjet në depo. Ka shumë shanse për të bërë një gabim, mund të harroni diçka ose të futni diçka që tashmë është lëshuar herën e fundit, ndonjëherë thjesht nuk është e qartë se çfarë të klasifikoni një kërkesë tërheqjeje si - a është kjo një veçori apo një rregullim gabimesh, apo teste redaktimi, ose diçka infrastrukturore.
Si mund të na ndihmojnë veprimet e GitHub? Ekziston një veprim i shkëlqyeshëm - hartuesi i lëshimit, ai ju lejon të vendosni një shabllon skedari të shënimeve të lëshimit për të vendosur kategoritë e kërkesave për tërheqje dhe t'i gruponi ato automatikisht në skedarin e shënimeve të lëshimit:
Shembull shabllon për konfigurimin e një raporti (.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
Shto një skript për të gjeneruar një draft version (.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 }}
Të gjitha kërkesat për tërheqje tani e tutje do të mblidhen automatikisht në shënimet e lëshimit - magjike!
Këtu mund të lindë pyetja: çka nëse zhvilluesit harrojnë të vendosin etiketa në PR? Atëherë nuk është e qartë se në cilën kategori duhet ta vendosni dhe përsëri do të duhet ta trajtoni manualisht, me secilën PR veç e veç. Për të rregulluar këtë problem, mund të përdorim një veprim tjetër - verifikuesin e etiketës - ai kontrollon praninë e etiketave në kërkesën për tërheqje. Nëse nuk ka etiketa të nevojshme, atëherë kontrolli do të dështojë dhe ne do të shohim një mesazh në lidhje me këtë në kërkesën tonë për tërheqje.
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'
Tani çdo kërkesë për tërheqje duhet të shënohet me një nga etiketat: lloji: rregullim, lloji: veçoritë, lloji: dokumentacioni, lloji: testet, lloji: konfigurimi.
Shënim automatik i kërkesave për tërheqje
Meqenëse prekëm një temë të tillë si puna efektive me kërkesat e tërheqjes, ia vlen të flasim për një veprim të tillë si etiketuesi, ai vendos etiketa në PR bazuar në të cilat skedarët janë ndryshuar. Për shembull, ne mund të shënojmë si [ndërtim] çdo kërkesë tërheqëse që përmban ndryshime në drejtori .github/workflow.
Lidhja e tij ë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 }}
Ne gjithashtu kemi nevojë për një skedar që përshkruan korrespondencën midis drejtorive të projektit dhe temave të kërkesës 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 pata sukses në çiftimin e veprimit që vendos automatikisht etiketat në kërkesat tërheqëse me veprimin që kontrollon praninë e etiketave të kërkuara; etiketa e përputhjes nuk dëshiron të shohë etiketat e shtuara nga roboti. Duket më e lehtë të shkruani veprimin tuaj që kombinon të dyja fazat. Por edhe në këtë formë është mjaft i përshtatshëm për t'u përdorur; duhet të zgjidhni një etiketë nga lista kur krijoni një kërkesë tërheqjeje.
Është koha për t'u vendosur
Provova disa opsione vendosjeje përmes GitHub Actions (nëpërmjet ssh, nëpërmjet scp dhe duke përdorur docker-hub), dhe mund të them se, ka shumë të ngjarë, do të gjeni një mënyrë për të ngarkuar binarin në server, pavarësisht sa i shtrembër është tubacioni juaj është.
Më pëlqeu opsioni i mbajtjes së të gjithë infrastrukturës në një vend, kështu që le të shohim se si të vendosemi në Paketat GitHub (kjo është një depo për përmbajtje binare, npm, jar, docker).
Skript për ndërtimin e një imazhi docker dhe publikimin e tij në Paketat 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 }}"
Së pari, ne duhet të ndërtojmë skedarin JAR të aplikacionit tonë, pas së cilës llogarisim shtegun për në regjistrin e dokerit GitHub dhe emrin e imazhit tonë. Këtu janë disa truke që nuk i kemi hasur ende:
- një ndërtim si: echo “::set-output name=NAME::VALUE” ju lejon të vendosni vlerën e një ndryshoreje në hapin aktual, në mënyrë që të mund të lexohet më pas në të gjithë hapat e tjerë.
- ju mund të merrni vlerën e grupit të ndryshores në hapin e mëparshëm përmes identifikuesit të këtij hapi: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Ndryshorja standarde GITHUB_REPOSITORY ruan emrin e depove dhe pronarit të saj ("pronari/emri i repo"). Për të prerë gjithçka nga kjo rresht, përveç emrit të depove, ne do të përdorim sintaksën bash: ${GITHUB_REPOSITORY#*/}
Më pas duhet të ndërtojmë imazhin e dokerit:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Hyni në regjistër:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Dhe publikoni imazhin në depon e paketave GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Për të treguar versionin e figurës, ne përdorim shifrat e para nga hash-i SHA i kryerjes - GITHUB_SHA ka edhe nuanca këtu, nëse bëni ndërtime të tilla jo vetëm kur bashkoheni në master, por edhe sipas krijimit të kërkesës për tërheqje ngjarje, atëherë SHA mund të mos përputhet me hash-in që shohim në historikun e git, sepse veprimi i veprimeve/kontrollit bën hash-in e tij unik për të shmangur veprimet bllokuese në PR.
Nëse gjithçka funksionoi mirë, atëherë duke hapur seksionin e paketave (https://github.com/antkorwin/github-actions/packages) në depo, do të shihni një imazh të ri docker:
Aty mund të shihni gjithashtu një listë të versioneve të imazhit të dokerit.
E tëra që mbetet është të konfigurojmë serverin tonë për të punuar me këtë regjistër dhe të rifillojmë shërbimin. Ndoshta do të flas se si ta bëj këtë përmes systemd një herë tjetër.
Monitorimi
Le të shohim një opsion të thjeshtë se si të bëjmë një kontroll shëndetësor për aplikacionin tonë duke përdorur GitHub Actions. Aplikacioni ynë i nisjes ka një aktivizues, kështu që ne nuk kemi nevojë të shkruajmë një API për të kontrolluar statusin e tij; ne kemi bërë tashmë gjithçka për dembelët. Thjesht duhet të tërhiqni hostin: 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"}
Gjithçka që na duhet është të shkruajmë një detyrë për të kontrolluar serverin duke përdorur cron, dhe nëse befas nuk na përgjigjet, atëherë do të dërgojmë një njoftim përmes telegramit.
Së pari, le të kuptojmë se si të ekzekutojmë një rrjedhë pune të cron:
on:
schedule:
- cron: '*/5 * * * *'
Është e thjeshtë, as nuk mund ta besoj se në Github mund të krijosh ngjarje që nuk përshtaten fare me webhooks. Detajet janë në dokumentacion:
Le të kontrollojmë statusin e serverit me dorë nëpërmjet 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"
Së pari, ruajmë në një variabël atë që serveri iu përgjigj kërkesës, në hapin tjetër kontrollojmë që statusi është UP dhe, nëse nuk është kështu, atëherë dalim me një gabim. Nëse keni nevojë të "mbushni" një veprim me duart tuaja, atëherë dalja 1 - armë e përshtatshme.
- 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 }}
Ne dërgojmë në telegram vetëm nëse veprimi dështoi në hapin e mëparshëm. Për të dërguar një mesazh, ne përdorim appleboy/telegram-action; mund të lexoni se si të merrni një bot token dhe ID të bisedës në dokumentacion:
Mos harroni të shkruani në sekretet në Github: URL për serverin dhe argumentet për botin e telegramit.
Pista bonus - JIRA për dembelët
Unë premtova se do të ktheheshim në JIRA dhe jemi kthyer. Qindra herë kam vëzhguar një situatë në stand-up kur zhvilluesit krijuan një veçori, shkrinë një degë, por harruan ta tërhiqnin problemin në JIRA. Sigurisht, nëse e gjithë kjo do të bëhej në një vend, do të ishte më e lehtë, por në fakt ne shkruajmë kodin në IDE, bashkojmë degët në bitbucket ose GitHub dhe më pas tërhiqni detyrat në Jira, për këtë duhet të hapim dritare të reja , ndonjëherë hyni përsëri dhe etj. Kur e mbani mend në mënyrë të përsosur atë që duhet të bëni më pas, atëherë nuk ka kuptim ta hapni përsëri tabelën. Si rezultat, në mëngjes në një standup ju duhet të kaloni kohë duke përditësuar bordin e detyrave.
GitHub do të na ndihmojë gjithashtu në këtë detyrë rutinë; për fillestarët, ne mund t'i tërheqim problemet automatikisht në kolonën code_review kur paraqesim një kërkesë për tërheqje. Gjithçka që duhet të bëni është të ndiqni konventën e emërtimit të degës:
[имя проекта]-[номер таска]-название
për shembull, nëse çelësi i projektit "GitHub Actions" është GA, atëherë GA-8-jira-bot mund të jetë një degë për zbatimin e detyrës GA-8.
Integrimi me JIRA funksionon përmes veprimeve nga Atlassian, nuk janë perfekte, duhet të them që disa prej tyre nuk më funksionuan fare. Por ne do të diskutojmë vetëm ato që patjetër funksionojnë dhe përdoren në mënyrë aktive.
Së pari ju duhet të identifikoheni në JIRA duke përdorur veprimin: 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 }}
Për ta bërë këtë, ju duhet të merrni një shenjë në JIRA, si ta bëni këtë përshkruhet këtu:
Ne nxjerrim identifikuesin e detyrës nga emri i degës:
- 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}}
Nëse kërkoni në tregun e GitHub, mund të gjeni një veprim për këtë detyrë, por më duhej të shkruaja të njëjtën gjë duke përdorur grep duke përdorur emrin e degës, sepse ky veprim nga Atlassian nuk donte të punonte në projektin tim në asnjë mënyrë. , për të kuptuar se çfarë nuk shkonte atje - më gjatë sesa të bëni të njëjtën gjë me duart tuaja.
E tëra që mbetet është të zhvendosni detyrën në kolonën "Rishikimi i kodit" kur krijoni një kërkesë për tërheqje:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Ekziston një veprim i veçantë për këtë në GitHub, gjithçka që i nevojitet është ID-ja e problemit të marrë në hapin e mëparshëm dhe autorizimi në JIRA që bëmë më lart.
Në të njëjtën mënyrë, ju mund të tërhiqni detyrat kur bashkohen në master, dhe ngjarje të tjera nga rrjedha e punës GitHub. Në përgjithësi, gjithçka varet nga imagjinata dhe dëshira juaj për të automatizuar proceset rutinë.
Gjetjet
Nëse shikoni diagramin klasik DEVOPS, ne kemi mbuluar të gjitha fazat, përveçse ndoshta funksionimin, mendoj se nëse provoni, mund të gjeni disa veprime në treg për integrimin me sistemin e ndihmës, kështu që do të supozojmë se tubacioni u kthye të jetë i plotë dhe mund të nxirren përfundime bazuar në përdorimin e tij.
Pro:
- Tregu me aksione të gatshme për të gjitha rastet, kjo është shumë e lezetshme. Në shumicën e tyre, ju gjithashtu mund të shikoni kodin burimor për të kuptuar se si të zgjidhni një problem të ngjashëm ose t'i postoni një kërkesë për veçori autorit direkt në depon e GitHub.
- Përzgjedhja e platformës së synuar për montim: Linux, mac os, Windows është një veçori mjaft interesante.
- Paketat Github janë një gjë e shkëlqyeshme, është e përshtatshme për të mbajtur të gjithë infrastrukturën në një vend, nuk keni nevojë të shfletoni nëpër dritare të ndryshme, gjithçka është brenda një rrezeje prej një ose dy klikimeve të miut dhe është e integruar në mënyrë të përkryer me GitHub Actions. Mbështetja e regjistrit Docker në versionin falas është gjithashtu një avantazh i mirë.
- GitHub fsheh sekretet në regjistrat e ndërtimit, kështu që përdorimi i tij për të ruajtur fjalëkalimet dhe argumentet nuk është aq i frikshëm. Gjatë gjithë eksperimenteve të mia, kurrë nuk munda ta shihja sekretin në formën e tij të pastër në tastierë.
- Falas për projekte me burim të hapur
Cons:
- YML, mirë, nuk më pëlqen ai. Kur punoni me një rrjedhë të tillë, mesazhi më i zakonshëm i commit që kam është "rregulloni formatin yml", pastaj harroni të vendosni një skedë diku, ose e shkruani në rreshtin e gabuar. Në përgjithësi, të ulesh para një ekrani me një raportues dhe vizore nuk është përvoja më e këndshme.
- DEBUG, korrigjimi i rrjedhës me commits, ekzekutimi i një rindërtimi dhe nxjerrja në tastierë nuk është gjithmonë i përshtatshëm, por është më shumë i kategorisë "ju jeni të tepruar"; jeni mësuar të punoni me IDEA të përshtatshme, kur mund të korrigjoni ndonjë gjë .
- Ju mund ta shkruani veprimin tuaj për çdo gjë nëse e mbështillni në Docker, por vetëm javascript mbështetet në mënyrë origjinale, sigurisht që kjo është çështje shije, por unë do të preferoja diçka tjetër në vend të js.
Më lejoni t'ju kujtoj se depoja me të gjitha skriptet është këtu:
Javën e ardhshme do të performoj me në konferencën Heisenbug 2020 Piter. Unë do t'ju tregoj jo vetëm se si të shmangni gabimet gjatë përgatitjes së të dhënave të provës, por gjithashtu do të ndaj sekretet e mia të punës me grupet e të dhënave në aplikacionet Java!
Burimi: www.habr.com