Yn aml mae'n rhaid i mi adeiladu piblinell ar gyfer prosiectau adeiladu yn Java. Weithiau mae'n ffynhonnell agored, weithiau nid yw. Yn ddiweddar, penderfynais geisio symud rhai o fy ystorfeydd o Travis-CI a TeamCity i GitHub Actions, a dyma beth ddaeth allan ohono.
Beth fyddwn ni'n ei awtomeiddio?
Yn gyntaf, mae angen prosiect y byddwn yn ei awtomeiddio, gadewch i ni wneud cais bach yn Spring boot / Java 11 / Maven. At ddibenion yr erthygl hon, ni fydd gennym ddiddordeb yn y rhesymeg ymgeisio o gwbl; mae'r seilwaith o amgylch y cais yn bwysig i ni, felly bydd rheolydd API REST syml yn ddigon i ni.
Gallwch weld y ffynonellau yma: Adlewyrchir pob cam o adeiladu piblinell yn y ceisiadau tynnu ar gyfer y prosiect hwn.
JIRA a chynllunio
Mae'n werth dweud ein bod fel arfer yn defnyddio JIRA fel traciwr materion, felly gadewch i ni greu bwrdd ar wahân ar gyfer y prosiect hwn ac ychwanegu'r rhifynnau cyntaf yno:
Ychydig yn ddiweddarach byddwn yn dychwelyd at ba bethau diddorol y gall JIRA a GitHub eu cynnig ar y cyd.
Rydym yn awtomeiddio cydosod y prosiect
Mae ein prosiect prawf yn cael ei adeiladu trwy maven, felly mae ei adeiladu yn eithaf syml, y cyfan sydd ei angen arnom yw'r pecyn glân mvn.
I wneud hyn gan ddefnyddio Github Actions, bydd angen creu ffeil yn y gadwrfa yn disgrifio ein llif gwaith, gellir gwneud hyn gyda ffeil yml rheolaidd, ni allaf ddweud fy mod yn hoffi “yml programmes”, ond beth allwn ni wneud - rydym yn ei wneud yn y llif gwaith .github/ directory/file build.yml lle byddwn yn disgrifio'r camau gweithredu wrth adeiladu'r brif gangen:
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 — mae hwn yn ddisgrifiad o'r digwyddiad y bydd ein sgript yn cael ei lansio arno.
ymlaen: pull_request/push - yn nodi bod angen lansio'r llif gwaith hwn bob tro y bydd ceisiadau meistr a thynnu yn cael eu creu.
Mae'r canlynol yn ddisgrifiad o'r tasgau (swyddi) a chamau gweithredu (camau) ar gyfer pob tasg.
rhedeg ymlaen - yma gallwn ddewis yr AO targed, yn syndod, gallwch hyd yn oed ddewis Mac OS, ond ar ystorfeydd preifat mae hyn yn eithaf drud (o'i gymharu â Linux).
defnyddio yn eich galluogi i ailddefnyddio gweithredoedd eraill, er enghraifft, gan ddefnyddio'r camau gweithredu/setup-java rydym yn gosod yr amgylchedd ar gyfer Java 11.
Trwy gyfrwng gyda gallwn nodi'r paramedrau ar gyfer lansio'r weithred, yn y bôn dyma'r dadleuon a drosglwyddir i'r weithred.
Y cyfan sydd ar ôl yw rhedeg y prosiect adeiladu yn Maven: run: mvn -B clean package baner -B yn dweud bod angen modd nad yw'n rhyngweithiol fel nad yw'r maven yn sydyn eisiau gofyn rhywbeth i ni
Gwych! Nawr, bob tro y byddwch chi'n ymrwymo i'r meistr, mae adeiladu'r prosiect yn dechrau.
Lansio profion awtomeiddio
Cynulliad yn dda, ond mewn gwirionedd, gall prosiect yn cael ei gydosod yn ddiogel, ond nid yn gweithio. Felly, y cam nesaf yw awtomeiddio'r rhediadau prawf. Yn ogystal, mae'n eithaf cyfleus edrych ar ganlyniadau pasio'r profion pan fyddwch chi'n gwneud adolygiad cysylltiadau cyhoeddus - rydych chi'n gwybod yn sicr bod y profion yn pasio ac nad oes neb wedi anghofio rhedeg eu cangen cyn uno.
Byddwn yn cynnal profion wrth greu cais tynnu ac yn uno i'r meistr, ac ar yr un pryd byddwn yn ychwanegu creu adroddiad ar gwmpas-cod.
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 }}
I gwmpasu profion, rwy'n defnyddio codecov ar y cyd â'r ategyn jacoco. Mae gan codecov ei weithred ei hun, ond mae angen tocyn i weithio gyda'n cais tynnu:
${{ secrets.CODECOV_TOKEN }} - byddwn yn gweld y lluniad hwn fwy nag unwaith, mae cyfrinachau yn fecanwaith ar gyfer storio cyfrinachau yn GitHub, gallwn ysgrifennu yno gyfrineiriau / tocynnau / gwesteiwyr / urls a data arall na ddylid ei gynnwys yn sylfaen cod y storfa.
Gallwch ychwanegu newidyn at gyfrinachau yng ngosodiadau'r ystorfa ar GitHub:
Gallwch gael tocyn yn Ar ôl awdurdodi trwy GitHub, i ychwanegu prosiect cyhoeddus does ond angen i chi ddilyn dolen fel hon: /[enw repo]. Gellir ychwanegu ystorfa breifat hefyd; i wneud hyn, mae angen ichi roi hawliau codecov i'r cais yn Github.
Ychwanegwch yr ategyn jacoco i'r ffeil 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>
Nawr bydd y bot codecov yn nodi pob un o'n ceisiadau tynnu ac yn ychwanegu graff newid sylw:
Gadewch i ni ychwanegu dadansoddwr statig
Yn y rhan fwyaf o'm prosiectau ffynhonnell agored rwy'n defnyddio cwmwl sonar ar gyfer dadansoddi cod statig, mae'n eithaf hawdd cysylltu â travis-ci. Felly mae'n gam rhesymegol wrth fudo i GitHub Actions i wneud yr un peth. Mae'r farchnad weithredu yn beth cŵl, ond y tro hwn fe wnaeth fy siomi ychydig, oherwydd allan o arfer fe wnes i ddod o hyd i'r weithred yr oeddwn ei angen a'i ychwanegu at y llif gwaith. Ond daeth i'r amlwg nad yw sonar yn cefnogi gweithio trwy weithred ar gyfer dadansoddi prosiectau ar maven neu gradle. Wrth gwrs, mae hyn wedi'i ysgrifennu yn y ddogfennaeth, ond pwy sy'n ei ddarllen?!
Nid yw'n bosibl trwy weithred, felly byddwn yn ei wneud trwy'r ategyn 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 - gellir ei gael yn ac mae angen ichi ei gofrestru yn gyfrinachol. GITHUB_TOKEN - mae hwn yn docyn adeiledig y mae GitHub yn ei gynhyrchu, gyda chymorth y bydd sonarcloud[bot] yn gallu mewngofnodi i Git er mwyn gadael negeseuon i ni mewn ceisiadau tynnu.
Dsonar.projectKey — enw'r prosiect yn y sonar, gallwch ei weld yng ngosodiadau'r prosiect.
Dsonar.sefydliad — enw'r sefydliad gan GitHub.
Rydyn ni'n gwneud cais tynnu ac yn aros i sonarcloud[bot] ddod yn y sylwadau:
Rheoli rhyddhau
Mae'r adeilad wedi'i ffurfweddu, mae'r profion wedi'u cynnal, a gallwn wneud datganiad. Gadewch i ni edrych ar sut y gall GitHub Actions wneud rheoli rhyddhau yn llawer haws.
Yn y gwaith, mae gen i brosiectau y mae eu sylfaen cod mewn bitbucket (mae popeth fel yn y stori honno “Rwy'n ysgrifennu at bitbucket yn ystod y dydd, yn ymrwymo i GitHub yn y nos”). Yn anffodus, nid oes gan bitbucket offer rheoli rhyddhau adeiledig. Mae hon yn broblem, oherwydd ar gyfer pob datganiad mae'n rhaid i chi greu tudalen â llaw mewn cydlifiad a thaflu'r holl nodweddion sydd wedi'u cynnwys yn y datganiad yno, chwilio trwy balasau'r meddwl, tasgau yn jira, yn ymrwymo yn y storfa. Mae yna lawer o gyfleoedd i wneud camgymeriad, gallwch chi anghofio rhywbeth neu nodi rhywbeth a ryddhawyd eisoes y tro diwethaf, weithiau nid yw'n glir beth i'w ddosbarthu fel cais tynnu - a yw'n nodwedd neu'n atgyweiriad nam, neu'n golygu profion, neu rhywbeth isadeileddol.
Sut gall gweithredoedd GitHub ein helpu ni? Mae yna weithred wych - drafftiwr rhyddhau, mae'n caniatáu ichi osod templed ffeil nodiadau rhyddhau i sefydlu categorïau o geisiadau tynnu a'u grwpio'n awtomatig yn y ffeil nodiadau rhyddhau:
Templed enghreifftiol ar gyfer sefydlu adroddiad (.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
Ychwanegu sgript i gynhyrchu datganiad drafft (.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 }}
Bydd pob cais tynnu o hyn ymlaen yn cael ei gasglu mewn nodiadau rhyddhau yn awtomatig - hud!
Yma gall y cwestiwn godi: beth os yw'r datblygwyr yn anghofio rhoi tagiau yn y cysylltiadau cyhoeddus? Yna nid yw'n glir pa gategori i'w roi ynddo, ac eto bydd yn rhaid i chi ddelio ag ef â llaw, gyda phob PR ar wahân. I ddatrys y broblem hon, gallwn ddefnyddio gweithred arall - dilysydd label - mae'n gwirio am bresenoldeb tagiau ar y cais tynnu. Os nad oes unrhyw dagiau gofynnol, yna bydd y siec yn cael ei methu a byddwn yn gweld neges am hyn yn ein cais tynnu.
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'
Nawr mae'n rhaid i unrhyw gais tynnu gael ei farcio ag un o'r tagiau: math: trwsiad, math: nodweddion, math: dogfennaeth, math: profion, math: ffurfwedd.
Awto-nodi ceisiadau tynnu
Ers i ni gyffwrdd â phwnc o'r fath fel gwaith effeithiol gyda cheisiadau tynnu, mae'n werth siarad am weithred o'r fath fel labeler, mae'n rhoi tagiau mewn cysylltiadau cyhoeddus yn seiliedig ar ba ffeiliau sydd wedi'u newid. Er enghraifft, gallwn farcio fel [adeiladu] unrhyw gais tynnu sy'n cynnwys newidiadau i'r cyfeiriadur .github/workflow.
Mae ei gysylltu yn eithaf syml:
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 }}
Rydym hefyd angen ffeil sy'n disgrifio'r ohebiaeth rhwng cyfeirlyfrau'r prosiect a phynciau'r ceisiadau tynnu:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Ni lwyddais i baru'r weithred sy'n gosod labeli yn awtomatig mewn ceisiadau tynnu gyda'r weithred sy'n gwirio am bresenoldeb labeli gofynnol; nid yw match-label am weld y labeli a ychwanegir gan y bot. Mae'n ymddangos yn haws ysgrifennu eich gweithred eich hun sy'n cyfuno'r ddau gam. Ond hyd yn oed yn y ffurflen hon mae'n eithaf cyfleus i'w ddefnyddio; mae angen i chi ddewis label o'r rhestr wrth greu cais tynnu.
Mae'n bryd defnyddio
Rhoddais gynnig ar sawl opsiwn defnyddio trwy GitHub Actions (trwy ssh, trwy scp, a defnyddio docker-hub), a gallaf ddweud, yn fwyaf tebygol, y byddwch yn dod o hyd i ffordd i uwchlwytho'r deuaidd i'r gweinydd, ni waeth pa mor gam yw'ch piblinell. yn.
Roeddwn i'n hoffi'r opsiwn o gadw'r seilwaith cyfan mewn un lle, felly gadewch i ni edrych ar sut i ddefnyddio Pecynnau GitHub (mae hon yn ystorfa ar gyfer cynnwys deuaidd, npm, jar, docwr).
Sgript ar gyfer adeiladu delwedd docwr a'i chyhoeddi mewn Pecynnau 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 }}"
Yn gyntaf, mae angen i ni adeiladu ffeil JAR ein cais, ac ar ôl hynny rydym yn cyfrifo'r llwybr i gofrestrfa docwyr GitHub ac enw ein delwedd. Mae yna ychydig o driciau yma nad ydym wedi dod ar eu traws eto:
- mae lluniad fel: adlais “::set-output name=ENW::VALUE” yn caniatáu ichi osod gwerth newidyn yn y cam cyfredol, fel y gellir ei ddarllen wedyn ym mhob cam arall.
- gallwch gael gwerth y newidyn a osodwyd yn y cam blaenorol trwy ddynodwr y cam hwn: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Mae'r newidyn safonol GITHUB_REPOSITORY yn storio enw'r gadwrfa a'i pherchennog (“perchennog/enw cadw”). Er mwyn torri popeth o'r llinell hon ac eithrio enw'r gadwrfa, byddwn yn defnyddio cystrawen bash: ${GITHUB_REPOSITORY#*/}
Nesaf mae angen i ni adeiladu delwedd y docwr:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Mewngofnodwch i'r gofrestrfa:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
A chyhoeddwch y ddelwedd i Storfa Pecynnau GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Er mwyn nodi fersiwn y ddelwedd, rydym yn defnyddio'r digidau cyntaf o'r hash SHA o'r ymrwymiad - GITHUB_SHA mae yna hefyd arlliwiau yma, os gwnewch adeiladau o'r fath nid yn unig wrth uno i feistr, ond hefyd yn ôl y cais tynnu creu digwyddiad, yna mae'n bosibl na fydd SHA yn cyfateb i'r hash a welwn yn hanes git, oherwydd mae'r camau gweithredu / siec yn gwneud ei hash unigryw ei hun i osgoi gweithredoedd cloi yn y cysylltiadau cyhoeddus.
Pe bai popeth wedi gweithio'n dda, yna agorwch yr adran becynnau ( https://github.com/antkorwin/github-actions/packages ) yn yr ystorfa, fe welwch ddelwedd docwr newydd:
Yno gallwch hefyd weld rhestr o fersiynau o ddelwedd y docwr.
Y cyfan sydd ar ôl yw ffurfweddu ein gweinydd i weithio gyda'r gofrestrfa hon ac ailgychwyn y gwasanaeth. Mae'n debyg y byddaf yn siarad am sut i wneud hyn trwy systemd dro arall.
Monitro
Gadewch i ni edrych ar opsiwn syml ar sut i wneud gwiriad iechyd ar gyfer ein cais gan ddefnyddio GitHub Actions. Mae gan ein cymhwysiad cist actiwadydd, felly nid oes angen i ni hyd yn oed ysgrifennu API i wirio ei statws; rydym eisoes wedi gwneud popeth i'r diog. Does ond angen i chi dynnu'r gwesteiwr: 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"}
Y cyfan sydd ei angen arnom yw ysgrifennu tasg i wirio'r gweinydd gan ddefnyddio cron, ac os yn sydyn nid yw'n ein hateb, yna byddwn yn anfon hysbysiad trwy telegram.
Yn gyntaf, gadewch i ni ddarganfod sut i redeg llif gwaith cron:
on:
schedule:
- cron: '*/5 * * * *'
Mae'n syml, ni allaf hyd yn oed gredu y gallwch chi yn Github greu digwyddiadau nad ydyn nhw'n ffitio i mewn i fachau gwe o gwbl. Mae manylion yn y ddogfennaeth:
Gadewch i ni wirio statws y gweinydd â llaw trwy 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"
Yn gyntaf, rydym yn cadw mewn newidyn yr hyn a ymatebodd y gweinydd i'r cais, yn y cam nesaf rydym yn gwirio bod y statws yn UP ac, os nad yw hyn yn wir, yna rydym yn gadael gyda gwall. Os oes angen i chi “orlethu” gweithred â'ch dwylo, yna allanfa 1 - arf addas.
- 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 }}
Dim ond os methodd y weithred yn y cam blaenorol y byddwn yn anfon at telegram. I anfon neges rydym yn defnyddio appleboy/telegram-action; gallwch ddarllen am sut i gael tocyn bot ac ID sgwrsio yn y ddogfennaeth:
Peidiwch ag anghofio ysgrifennu'r cyfrinachau ar Github: URL ar gyfer y gweinydd a thocynnau ar gyfer y bot telegram.
Trac bonws - JIRA i'r diog
Addewais y byddem yn dychwelyd i JIRA, ac rydym wedi dychwelyd. Gannoedd o weithiau rwyf wedi sylwi ar sefyllfa ar stand-ups pan wnaeth datblygwyr nodwedd, uno cangen, ond anghofio llusgo'r mater i JIRA. Wrth gwrs, pe bai hyn i gyd yn cael ei wneud mewn un lle, byddai'n haws, ond mewn gwirionedd rydym yn ysgrifennu cod yn yr IDE, yn uno canghennau i bitbucket neu GitHub, ac yna llusgo'r tasgau i Jira, ar gyfer hyn mae angen i ni agor ffenestri newydd , weithiau mewngofnodi eto ac ati. Pan fyddwch chi'n cofio'n berffaith beth sydd angen i chi ei wneud nesaf, yna does dim pwynt agor y bwrdd eto. O ganlyniad, yn y bore ar standup mae angen i chi dreulio amser yn diweddaru'r bwrdd tasgau.
Bydd GitHub hefyd yn ein helpu yn y dasg arferol hon; i ddechreuwyr, gallwn lusgo materion yn awtomatig i'r golofn code_review pan fyddwn yn cyflwyno cais tynnu. Y cyfan sydd angen i chi ei wneud yw dilyn y confensiwn enwi cangen:
[имя проекта]-[номер таска]-название
er enghraifft, os yw allwedd y prosiect "GitHub Actions" yn GA, yna GA-8-jira-bot gallai fod yn gangen ar gyfer gweithredu tasg GA-8.
Mae integreiddio â JIRA yn gweithio trwy weithredoedd o Atlassian, nid ydynt yn berffaith, rhaid i mi ddweud nad oedd rhai ohonynt yn gweithio i mi o gwbl. Ond byddwn yn trafod dim ond y rhai sy'n bendant yn gweithio ac yn cael eu defnyddio'n weithredol.
Yn gyntaf mae angen i chi fewngofnodi i JIRA gan ddefnyddio'r weithred: 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 }}
I wneud hyn, mae angen i chi gael tocyn yn JIRA, disgrifir sut i wneud hyn yma:
Rydym yn tynnu'r dynodwr tasg o enw'r gangen:
- 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}}
Os chwiliwch yn y farchnad GitHub, gallwch ddod o hyd i weithred ar gyfer y dasg hon, ond bu'n rhaid i mi ysgrifennu'r un peth gan ddefnyddio grep gan ddefnyddio enw'r gangen, oherwydd nid oedd y weithred hon gan Atlassian eisiau gweithio ar fy mhrosiect mewn unrhyw ffordd , i ddarganfod beth oedd yn bod yno - yn hirach na gwneud yr un peth â'ch dwylo.
Y cyfan sydd ar ôl yw symud y dasg i'r golofn “Cod review” wrth greu cais tynnu:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Mae cam gweithredu arbennig ar gyfer hyn ar GitHub, y cyfan sydd ei angen arno yw'r ID mater a gafwyd yn y cam blaenorol a'r awdurdodiad yn JIRA a wnaethom uchod.
Yn yr un modd, gallwch lusgo tasgau wrth uno i'r meistr, a digwyddiadau eraill o lif gwaith GitHub. Yn gyffredinol, mae'r cyfan yn dibynnu ar eich dychymyg a'ch awydd i awtomeiddio prosesau arferol.
Canfyddiadau
Os edrychwch ar y diagram DEVOPS clasurol, rydym wedi ymdrin â phob cam, ac eithrio gweithredu efallai, rwy'n meddwl os ceisiwch, gallwch ddod o hyd i rywfaint o gamau gweithredu yn y farchnad ar gyfer integreiddio â'r system desg gymorth, felly byddwn yn tybio bod y biblinell wedi troi. allan i fod yn drylwyr a gellir dod i gasgliadau ar sail ei ddefnydd.
Manteision:
- Marchnad gyda gweithredoedd parod ar gyfer pob achlysur, mae hyn yn cŵl iawn. Yn y rhan fwyaf ohonynt, gallwch hefyd edrych ar y cod ffynhonnell i ddeall sut i ddatrys problem debyg neu bostio cais nodwedd i'r awdur yn uniongyrchol yn ystorfa GitHub.
- Mae dewis y platfform targed ar gyfer cydosod: Linux, mac os, windows yn nodwedd eithaf diddorol.
- Mae Pecynnau Github yn beth gwych, mae'n gyfleus cadw'r seilwaith cyfan mewn un lle, nid oes rhaid i chi syrffio trwy wahanol ffenestri, mae popeth o fewn radiws o un neu ddau o gliciau llygoden ac wedi'i integreiddio'n berffaith â GitHub Actions. Mae cefnogaeth cofrestrfa docwr yn y fersiwn am ddim hefyd yn fantais dda.
- Mae GitHub yn cuddio cyfrinachau mewn logiau adeiladu, felly nid yw ei ddefnyddio i storio cyfrineiriau a thocynnau mor frawychus â hynny. Yn ystod fy holl arbrofion, doeddwn i byth yn gallu gweld y gyfrinach yn ei ffurf pur yn y consol.
- Am ddim ar gyfer prosiectau Ffynhonnell Agored
Cons:
- YML, wel, dydw i ddim yn ei hoffi. Wrth weithio gyda llif o'r fath, y neges ymrwymo fwyaf cyffredin sydd gen i yw "fix yml format", yna rydych chi'n anghofio rhoi tab yn rhywle, neu rydych chi'n ei ysgrifennu ar y llinell anghywir. Yn gyffredinol, nid eistedd o flaen sgrin gydag onglydd a phren mesur yw'r profiad mwyaf dymunol.
- Nid yw DEBUG, dadfygio'r llif gydag ymrwymiadau, rhedeg ailadeiladu, ac allbynnu i'r consol bob amser yn gyfleus, ond mae'n fwy o'r categori “rydych chi wedi gorwneud”; rydych chi wedi arfer gweithio gyda IDEA cyfleus, pan allwch chi ddadfygio unrhyw beth .
- Gallwch chi ysgrifennu eich gweithred ar unrhyw beth os ydych chi'n ei lapio yn Docker, ond dim ond javascript sy'n cael ei gefnogi'n frodorol, wrth gwrs mae hyn yn fater o flas, ond byddai'n well gennyf rywbeth arall yn lle js.
Gadewch imi eich atgoffa bod y storfa gyda'r holl sgriptiau yma:
Wythnos nesaf byddaf yn perfformio gyda yng nghynhadledd Heisenbug 2020 Piter. Byddaf yn dweud wrthych nid yn unig sut i osgoi camgymeriadau wrth baratoi data prawf, ond hefyd yn rhannu fy nghyfrinachau o weithio gyda setiau data mewn cymwysiadau Java!
Ffynhonnell: hab.com