Madalas kong kailangang bumuo ng pipeline para sa pagbuo ng mga proyekto sa Java. Minsan open source, minsan hindi. Kamakailan ay nagpasya akong subukang ilipat ang ilan sa aking mga repository mula sa Travis-CI at TeamCity sa GitHub Actions, at ito ang lumabas dito.
Ano ang i-automate natin?
Una, kailangan namin ng isang proyekto na aming i-automate, gumawa tayo ng isang maliit na aplikasyon sa Spring boot / Java 11 / Maven. Para sa mga layunin ng artikulong ito, hindi kami magiging interesado sa lohika ng aplikasyon; ang imprastraktura sa paligid ng application ay mahalaga sa amin, kaya ang isang simpleng REST API controller ay sapat na para sa amin.
Maaari mong tingnan ang mga mapagkukunan dito: Ang lahat ng mga yugto ng pagbuo ng pipeline ay makikita sa mga pull request para sa proyektong ito.
JIRA at pagpaplano
Marapat na sabihin na karaniwan naming ginagamit ang JIRA bilang tagasubaybay ng isyu, kaya gumawa tayo ng hiwalay na board para sa proyektong ito at idagdag ang mga unang isyu doon:
Maya-maya ay babalik tayo sa kung anong mga kawili-wiling bagay ang maiaalok ng JIRA at GitHub sa kumbinasyon.
Awtomatiko namin ang pagpupulong ng proyekto
Ang aming proyekto sa pagsubok ay binuo sa pamamagitan ng maven, kaya ang pagbuo nito ay medyo simple, ang kailangan lang namin ay ang mvn clean package.
Upang gawin ito gamit ang Github Actions, kakailanganin naming lumikha ng isang file sa repositoryo na naglalarawan sa aming daloy ng trabaho, maaari itong gawin sa isang regular na yml file, hindi ko masasabi na gusto ko ang "yml programming", ngunit ano ang magagawa namin - ginagawa namin ito sa .github/ directory workflow/ file build.yml kung saan ilalarawan namin ang mga aksyon kapag binubuo ang master branch:
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 β ito ay isang paglalarawan ng kaganapan kung saan ilulunsad ang aming script.
sa: pull_request/push β ay nagsasaad na ang workflow na ito ay kailangang ilunsad sa tuwing may gagawing push sa master at ang mga pull request ay gagawin.
Ang sumusunod ay isang paglalarawan ng mga gawain (trabaho) at mga hakbang sa pagpapatupad (hakbang) para sa bawat gawain.
ay tumatakbo sa - dito maaari naming piliin ang target na OS, nakakagulat, maaari mo ring piliin ang Mac OS, ngunit sa mga pribadong repositoryo ito ay medyo mahal (kumpara sa Linux).
Gumagamit ay nagbibigay-daan sa iyong muling gumamit ng iba pang mga aksyon, halimbawa, gamit ang actions/setup-java action na ini-install namin ang environment para sa Java 11.
Sa pamamagitan ng sa maaari naming tukuyin ang mga parameter kung saan namin ilulunsad ang aksyon, mahalagang ito ang mga argumento na ipapasa sa aksyon.
Ang natitira na lang ay patakbuhin ang pagbuo ng proyekto sa Maven: run: mvn -B clean package bandila -B sabi na kailangan namin ng non-interactive mode para biglang ayaw magtanong sa amin ng maven
Malaki! Ngayon, sa bawat oras na mag-commit ka sa master, magsisimula ang pagbuo ng proyekto.
Pag-automate ng paglulunsad ng pagsubok
Ang pagpupulong ay mabuti, ngunit sa katotohanan, ang isang proyekto ay maaaring tipunin nang ligtas, ngunit hindi gumagana. Samakatuwid, ang susunod na hakbang ay i-automate ang mga pagsubok na tumatakbo. Bilang karagdagan, medyo maginhawang tingnan ang mga resulta ng pagpasa sa mga pagsusulit kapag gumawa ka ng isang pagsusuri sa PR - alam mong sigurado na ang mga pagsusulit ay pumasa at walang nakalimutan na patakbuhin ang kanilang sangay bago gumawa ng isang pagsasanib.
Magsasagawa kami ng mga pagsubok kapag gumagawa ng pull request at sumanib sa master, at kasabay nito ay idaragdag namin ang paglikha ng isang ulat sa code-coverage.
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 }}
Upang masakop ang mga pagsubok, gumagamit ako ng codecov kasabay ng jacoco plugin. Ang codecov ay may sariling aksyon, ngunit kailangan nito ng token upang gumana sa aming kahilingan sa paghila:
${{ secrets.CODECOV_TOKEN }} β makikita natin ang konstruksiyon na ito nang higit sa isang beses, ang mga lihim ay isang mekanismo para sa pag-iimbak ng mga lihim sa GitHub, maaari tayong sumulat doon ng mga password/token/host/url at iba pang data na hindi dapat isama sa base ng repositoryo.
Maaari kang magdagdag ng variable sa mga lihim sa mga setting ng repository sa GitHub:
Maaari kang makakuha ng token sa Pagkatapos ng pahintulot sa pamamagitan ng GitHub, para magdagdag ng pampublikong proyekto kailangan mo lang sundin ang isang link na tulad nito: /[repo name]. Maaari ding magdagdag ng pribadong repositoryo; para magawa ito, kailangan mong magbigay ng mga karapatan sa codecov sa application sa Github.
Idagdag ang jacoco plugin sa POM file:
<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>
Ngayon, ilalagay ng codecov bot ang bawat isa sa aming mga pull request at magdagdag ng graph ng pagbabago sa saklaw:
Magdagdag tayo ng static analyzer
Sa karamihan ng aking mga open source na proyekto ay gumagamit ako ng sonar cloud para sa static code analysis, medyo madali itong kumonekta sa travis-ci. Kaya ito ay isang lohikal na hakbang kapag lumilipat sa GitHub Actions upang gawin ang pareho. Ang merkado ng aksyon ay isang cool na bagay, ngunit sa pagkakataong ito ay pinabayaan ako nito nang kaunti, dahil sa ugali ay natagpuan ko ang aksyon na kailangan ko at idinagdag ito sa daloy ng trabaho. Ngunit lumabas na hindi sinusuportahan ng sonar ang pagtatrabaho sa pamamagitan ng isang aksyon para sa pagsusuri ng mga proyekto sa maven o gradle. Siyempre, nakasulat ito sa dokumentasyon, ngunit sino ang nagbabasa nito?!
Hindi ito posible sa pamamagitan ng isang aksyon, kaya gagawin namin ito sa pamamagitan ng 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 - maaaring makuha sa at kailangan mong irehistro ito sa mga lihim. GITHUB_TOKEN - ito ay isang built-in na token na binubuo ng GitHub, sa tulong kung saan ang sonarcloud[bot] ay makakapag-log in sa Git upang mag-iwan sa amin ng mga mensahe sa mga pull request.
Dsonar.projectKey β ang pangalan ng proyekto sa sonar, makikita mo ito sa mga setting ng proyekto.
Dsonar.organisasyon β pangalan ng organisasyon mula sa GitHub.
Gumagawa kami ng pull request at naghihintay na dumating ang sonarcloud[bot] sa mga komento:
Pamamahala ng paglabas
Na-configure na ang build, naisagawa na ang mga pagsubok, at makakagawa na tayo ng release. Tingnan natin kung paano mapadali ng GitHub Actions ang pamamahala ng release.
Sa trabaho, mayroon akong mga proyekto na ang base ng code ay nasa bitbucket (lahat ng bagay ay tulad ng sa kuwentong iyon "Sumusulat ako sa bitbucket sa araw, commit sa GitHub sa gabi"). Sa kasamaang palad, ang bitbucket ay walang built-in na mga tool sa pamamahala ng release. Ito ay isang problema, dahil para sa bawat release kailangan mong manu-manong lumikha ng isang pahina sa confluence at itapon ang lahat ng mga tampok na kasama sa release doon, maghanap sa mga palasyo ng isip, mga gawain sa jira, commits sa repositoryo. Maraming pagkakataong magkamali, maaari kang makalimot ng isang bagay o magpasok ng isang bagay na nai-release na noong nakaraan, kung minsan ay hindi malinaw kung ano ang iuuri bilang isang pull request - ito ba ay isang tampok o isang pag-aayos ng bug, o mga pagsubok sa pag-edit, o isang bagay na imprastraktura.
Paano tayo matutulungan ng mga pagkilos ng GitHub? Mayroong isang mahusay na aksyon - release drafter, binibigyang-daan ka nitong magtakda ng template ng file ng mga tala ng paglabas upang mag-set up ng mga kategorya ng mga kahilingan sa pag-pull at awtomatikong pagpangkatin ang mga ito sa file ng mga tala ng paglabas:
Halimbawang template para sa pag-set up ng isang ulat (.github/release-draafter.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
Magdagdag ng script para makabuo ng draft release (.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 }}
Lahat ng pull request mula ngayon ay awtomatikong kokolektahin sa mga release note - magic!
Dito maaaring lumitaw ang tanong: paano kung nakalimutan ng mga developer na maglagay ng mga tag sa PR? Pagkatapos ay hindi malinaw kung aling kategorya ang ilalagay nito, at muli ay kailangan mong harapin ito nang manu-mano, sa bawat PR nang hiwalay. Upang ayusin ang problemang ito, maaari kaming gumamit ng isa pang pagkilos - verifier ng label - sinusuri nito ang pagkakaroon ng mga tag sa kahilingan sa paghila. Kung walang kinakailangang mga tag, mabibigo ang tseke at makakakita kami ng mensahe tungkol dito sa aming kahilingan sa paghila.
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'
Ngayon ang anumang pull-request ay dapat na markahan ng isa sa mga tag: type:fix, type:features, type:documentation, type:tests, type:config.
Auto-annotation ng mga pull request
Dahil hinawakan namin ang paksang tulad ng epektibong trabaho sa mga kahilingan sa pag-pull, sulit na pag-usapan ang tungkol sa pagkilos bilang labeler, naglalagay ito ng mga tag sa PR batay sa kung aling mga file ang nabago. Halimbawa, maaari naming markahan bilang [bumuo] ng anumang kahilingan sa paghila na naglalaman ng mga pagbabago sa direktoryo .github/workflow.
Ang pagkonekta nito ay medyo simple:
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 }}
Kailangan din namin ng isang file na naglalarawan sa pagsusulatan sa pagitan ng mga direktoryo ng proyekto at ng mga paksa ng pull request:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Hindi ako nagtagumpay sa pagpapares ng aksyon na awtomatikong naglalagay ng mga label sa mga pull request sa pagkilos na tumitingin sa pagkakaroon ng mga kinakailangang label; ayaw makita ng match-label ang mga label na idinagdag ng bot. Mukhang mas madaling isulat ang iyong sariling aksyon na pinagsasama ang parehong mga yugto. Ngunit kahit na sa form na ito ay medyo maginhawang gamitin, kailangan mong pumili ng isang label mula sa listahan kapag lumilikha ng isang kahilingan sa paghila.
Oras na para mag-deploy
Sinubukan ko ang ilang mga opsyon sa pag-deploy sa pamamagitan ng GitHub Actions (sa pamamagitan ng ssh, sa pamamagitan ng scp, at paggamit ng docker-hub), at masasabi ko na, malamang, makakahanap ka ng paraan upang i-upload ang binary sa server, gaano man kabaluktot ang iyong pipeline ay.
Nagustuhan ko ang opsyon na panatilihin ang buong imprastraktura sa isang lugar, kaya tingnan natin kung paano mag-deploy sa GitHub Packages (ito ay isang repository para sa binary na nilalaman, npm, jar, docker).
Script para sa pagbuo ng isang docker na imahe at pag-publish nito sa GitHub Packages:
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 }}"
Una, kailangan naming buuin ang JAR file ng aming application, pagkatapos ay kalkulahin namin ang path sa GitHub docker registry at ang pangalan ng aming imahe. Mayroong ilang mga trick dito na hindi pa natin nakikita:
- ang isang construction tulad ng: echo β::set-output name=NAME::VALUEβ ay nagbibigay-daan sa iyo na itakda ang halaga ng isang variable sa kasalukuyang hakbang, nang sa gayon ay mababasa ito sa lahat ng iba pang hakbang.
- maaari mong makuha ang halaga ng variable na itinakda sa nakaraang hakbang sa pamamagitan ng identifier ng hakbang na ito: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Ang karaniwang GITHUB_REPOSITORY variable ay nag-iimbak ng pangalan ng repositoryo at ang may-ari nito ("may-ari/repo-pangalan"). Upang maputol ang lahat mula sa linyang ito maliban sa pangalan ng repositoryo, gagamitin namin ang bash syntax: ${GITHUB_REPOSITORY#*/}
Susunod na kailangan nating buuin ang imahe ng docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Mag-log in sa registry:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
At i-publish ang imahe sa GitHub Packages Repository:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Upang ipahiwatig ang bersyon ng imahe, ginagamit namin ang mga unang digit mula sa SHA hash ng commit - GITHUB_SHA mayroon ding mga nuances dito, kung gumawa ka ng mga naturang build hindi lamang kapag pinagsama sa master, kundi pati na rin ayon sa paggawa ng pull request kaganapan, kung gayon ang SHA ay maaaring hindi tumugma sa hash na nakikita natin sa git history, dahil ang mga aksyon/pag-checkout na pagkilos ay gumagawa ng sarili nitong natatanging hash upang maiwasan ang mga deadlocking na pagkilos sa PR.
Kung maayos ang lahat, pagkatapos ay buksan ang seksyon ng mga pakete (https://github.com/antkorwin/github-actions/packages) sa repositoryo, makakakita ka ng bagong imahe ng docker:
Doon ay makikita mo rin ang isang listahan ng mga bersyon ng docker image.
Ang natitira na lang ay i-configure ang aming server upang gumana sa registry na ito at i-restart ang serbisyo. Malamang na pag-uusapan ko kung paano ito gagawin sa pamamagitan ng systemd sa ibang pagkakataon.
Pagsubaybay
Tingnan natin ang isang simpleng opsyon kung paano gumawa ng pagsusuri sa kalusugan para sa aming application gamit ang GitHub Actions. Ang aming boot application ay may actuator, kaya hindi na namin kailangan pang magsulat ng API para suriin ang status nito; nagawa na namin ang lahat para sa mga tamad. Kailangan mo lang hilahin ang 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"}
Ang kailangan lang namin ay magsulat ng isang gawain upang suriin ang server gamit ang cron, at kung bigla itong hindi sumagot sa amin, pagkatapos ay magpapadala kami ng isang abiso sa pamamagitan ng telegrama.
Una, alamin natin kung paano magpatakbo ng cron workflow:
on:
schedule:
- cron: '*/5 * * * *'
Simple lang, hindi ako makapaniwala na sa Github makakagawa ka ng mga event na hindi nababagay sa mga webhook. Ang mga detalye ay nasa dokumentasyon:
Suriin natin ang status ng server nang manu-mano sa pamamagitan ng 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"
Una, ise-save namin sa isang variable kung ano ang tinugon ng server sa kahilingan, sa susunod na hakbang ay tinitingnan namin na ang status ay UP at, kung hindi ito ang kaso, pagkatapos ay lumabas kami nang may error. Kung kailangan mong "mapuspos" ang isang aksyon gamit ang iyong mga kamay, kung gayon labasan 1 - angkop na sandata.
- 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 }}
Nagpapadala lamang kami sa telegrama kung nabigo ang pagkilos sa nakaraang hakbang. Upang magpadala ng mensahe ay gumagamit kami ng appleboy/telegram-action; maaari mong basahin ang tungkol sa kung paano makakuha ng bot token at chat id sa dokumentasyon:
Huwag kalimutang isulat ang mga lihim sa Github: URL para sa server at mga token para sa telegram bot.
Bonus track - JIRA para sa mga tamad
Nangako ako na babalik kami sa JIRA, at bumalik na kami. Daan-daang beses kong naobserbahan ang isang sitwasyon sa mga stand-up nang gumawa ng feature ang mga developer, nagsama ng branch, ngunit nakalimutang i-drag ang isyu sa JIRA. Siyempre, kung ang lahat ng ito ay ginawa sa isang lugar, magiging mas madali, ngunit sa katunayan sumulat kami ng code sa IDE, pinagsama ang mga sanga sa bitbucket o GitHub, at pagkatapos ay i-drag ang mga gawain sa Jira, para dito kailangan naming magbukas ng mga bagong window , minsan mag log in ulit and etc. Kapag ganap mong naaalala kung ano ang kailangan mong gawin sa susunod, walang saysay na buksan muli ang board. Bilang resulta, sa umaga sa isang standup kailangan mong gumugol ng oras sa pag-update ng task board.
Tutulungan din kami ng GitHub sa nakagawiang gawaing ito; bilang panimula, maaari naming awtomatikong i-drag ang mga isyu sa column ng code_review kapag nagsumite kami ng pull request. Ang kailangan mo lang gawin ay sundin ang kombensiyon sa pagpapangalan ng sangay:
[ΠΈΠΌΡ ΠΏΡΠΎΠ΅ΠΊΡΠ°]-[Π½ΠΎΠΌΠ΅Ρ ΡΠ°ΡΠΊΠ°]-Π½Π°Π·Π²Π°Π½ΠΈΠ΅
halimbawa, kung ang project key na "GitHub Actions" ay GA, kung gayon GA-8-jira-bot maaaring maging sangay para sa pagpapatupad ng gawain ng GA-8.
Ang pagsasama sa JIRA ay gumagana sa pamamagitan ng mga aksyon mula sa Atlassian, hindi sila perpekto, dapat kong sabihin na ang ilan sa mga ito ay hindi gumana para sa akin. Ngunit tatalakayin lamang natin ang mga tiyak na gumagana at aktibong ginagamit.
Una kailangan mong mag-log in sa JIRA gamit ang aksyon: 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 }}
Para magawa ito, kailangan mong makakuha ng token sa JIRA, kung paano ito gagawin ay inilarawan dito:
Kinukuha namin ang task identifier mula sa pangalan ng sangay:
- 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}}
Kung maghahanap ka sa GitHub marketplace, makakahanap ka ng isang aksyon para sa gawaing ito, ngunit kailangan kong isulat ang parehong bagay gamit ang grep gamit ang pangalan ng sangay, dahil ang aksyon na ito mula sa Atlassian ay hindi nais na gumana sa aking proyekto sa anumang paraan , upang malaman kung ano ang mali doon - mas matagal kaysa sa paggawa ng parehong bagay gamit ang iyong mga kamay.
Ang natitira na lang ay ilipat ang gawain sa column na "Pagsusuri ng code" kapag gumagawa ng pull request:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Mayroong espesyal na pagkilos para dito sa GitHub, ang kailangan lang nito ay ang issue ID na nakuha sa nakaraang hakbang at ang awtorisasyon sa JIRA na ginawa namin sa itaas.
Sa parehong paraan, maaari mong i-drag ang mga gawain kapag pinagsama sa master, at iba pang mga kaganapan mula sa workflow ng GitHub. Sa pangkalahatan, ang lahat ay nakasalalay sa iyong imahinasyon at pagnanais na i-automate ang mga nakagawiang proseso.
Natuklasan
Kung titingnan mo ang klasikong diagram ng DEVOPS, sinakop namin ang lahat ng mga yugto, maliban sa marahil ay gumana, sa palagay ko kung susubukan mo, makakahanap ka ng ilang aksyon sa merkado para sa pagsasama sa sistema ng help-desk, kaya ipagpalagay namin na ang pipeline ay nakabukas. maging masinsinan at maaaring makagawa ng mga konklusyon batay sa paggamit nito.
Pros:
- Marketplace na may mga handa na aksyon para sa lahat ng okasyon, ito ay napaka-cool. Sa karamihan sa mga ito, maaari mo ring tingnan ang source code upang maunawaan kung paano lutasin ang isang katulad na problema o mag-post ng kahilingan sa tampok sa may-akda nang direkta sa imbakan ng GitHub.
- Ang pagpili ng target na platform para sa pagpupulong: Linux, mac os, windows ay isang kawili-wiling tampok.
- Ang Github Packages ay isang magandang bagay, ito ay maginhawa upang panatilihin ang buong imprastraktura sa isang lugar, hindi mo kailangang mag-surf sa iba't ibang mga bintana, lahat ay nasa radius ng isa o dalawang pag-click ng mouse at perpektong isinama sa GitHub Actions. Ang suporta sa pagpapatala ng Docker sa libreng bersyon ay isa ring magandang kalamangan.
- Itinatago ng GitHub ang mga lihim sa mga build log, kaya hindi ganoon katakot ang paggamit nito upang mag-imbak ng mga password at token. Sa lahat ng aking mga eksperimento, hindi ko kailanman nakita ang lihim sa dalisay nitong anyo sa console.
- Libre para sa mga proyektong Open Source
Cons:
- YML, well, hindi ko siya gusto. Kapag nagtatrabaho sa ganoong daloy, ang pinakakaraniwang commit message na mayroon ako ay "fix yml format", pagkatapos ay nakalimutan mong maglagay ng tab sa isang lugar, o isulat mo ito sa maling linya. Sa pangkalahatan, ang pag-upo sa harap ng screen na may protractor at ruler ay hindi ang pinakamasayang karanasan.
- Ang pag-DEBUG, pag-debug ng daloy gamit ang mga commit, pagpapatakbo ng isang muling pagtatayo, at pag-output sa console ay hindi palaging maginhawa, ngunit ito ay higit pa sa kategoryang "nasobrahan ka na"; sanay kang magtrabaho kasama ang maginhawang IDEA, kapag maaari mong i-debug ang anumang bagay .
- Maaari mong isulat ang iyong aksyon sa anumang bagay kung ibalot mo ito sa Docker, ngunit ang javascript lamang ang katutubong suportado, siyempre ito ay isang bagay ng panlasa, ngunit mas gusto ko ang ibang bagay sa halip na js.
Hayaan akong ipaalala sa iyo na ang repository na may lahat ng mga script ay narito:
Sa susunod na linggo ay magpe-perform ako sa Heisenbug 2020 Piter conference. Sasabihin ko sa iyo hindi lamang kung paano maiwasan ang mga pagkakamali kapag naghahanda ng data ng pagsubok, ngunit ibahagi din ang aking mga lihim ng pagtatrabaho sa mga set ng data sa mga application ng Java!
Pinagmulan: www.habr.com