Mara nyingi mimi hulazimika kujenga bomba kwa miradi ya ujenzi huko Java. Wakati mwingine ni chanzo wazi, wakati mwingine sivyo. Hivi majuzi niliamua kujaribu kuhamisha hazina zangu kutoka Travis-CI na TeamCity hadi Vitendo vya GitHub, na hii ndio iliyotoka.
Tutafanya nini kiotomatiki?
Kwanza, tunahitaji mradi ambao tutafanya otomatiki, wacha tufanye programu ndogo katika Boot ya Spring / Java 11 / Maven. Kwa madhumuni ya kifungu hiki, hatutavutiwa na mantiki ya programu hata kidogo; miundombinu karibu na programu ni muhimu kwetu, kwa hivyo kidhibiti rahisi cha REST API kitatutosha.
Unaweza kutazama vyanzo hapa: Hatua zote za ujenzi wa bomba zinaonyeshwa katika maombi ya kuvuta kwa mradi huu.
JIRA na kupanga
Inafaa kusema kuwa kwa kawaida sisi hutumia JIRA kama kifuatilia masuala, kwa hivyo hebu tuunde ubao tofauti wa mradi huu na tuongeze masuala ya kwanza hapo:
Baadaye kidogo tutarudi kwa mambo gani ya kupendeza ambayo JIRA na GitHub wanaweza kutoa kwa pamoja.
Tunatengeneza kiotomatiki mkusanyiko wa mradi
Mradi wetu wa majaribio umejengwa kupitia maven, kwa hivyo kuijenga ni rahisi sana, tunachohitaji ni kifurushi cha mvn safi.
Ili kufanya hivyo kwa kutumia Vitendo vya Github, tutahitaji kuunda faili kwenye hazina inayoelezea mtiririko wetu wa kazi, hii inaweza kufanywa na faili ya kawaida ya yml, siwezi kusema kuwa napenda "yml programming", lakini tunaweza kufanya nini - tunaifanya katika .github/ directory workflow/ file build.yml ambamo tutaelezea vitendo wakati wa kujenga tawi kuu:
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 - haya ni maelezo ya tukio ambalo hati yetu itazinduliwa.
kwenye: pull_request/push - inaonyesha kuwa mtiririko huu wa kazi unahitaji kuzinduliwa kila wakati msukumo unapofanywa kwa bwana na maombi ya kuvuta yanapoundwa.
Yafuatayo ni maelezo ya kazi (ajira) na hatua za utekelezaji (hatua) kwa kila kazi.
inaendeshwa - hapa tunaweza kuchagua OS inayolengwa, kwa kushangaza, unaweza hata kuchagua Mac OS, lakini kwenye hazina za kibinafsi hii ni ghali kabisa (ikilinganishwa na Linux).
matumizi hukuruhusu kutumia tena vitendo vingine, kwa mfano, kwa kutumia vitendo/kitendo cha kuweka-java tunachosakinisha mazingira kwa Java 11.
Kwa njia ya na tunaweza kubainisha vigezo ambavyo tutazindua kitendo, kimsingi hizi ndizo hoja zitakazopitishwa kwa kitendo.
Kilichobaki ni kuendesha mradi wa ujenzi na Maven: run: mvn -B clean package bendera -B inasema kwamba tunahitaji hali isiyo ya maingiliano ili maven ghafla hataki kutuuliza kitu
Kubwa! Sasa, kila wakati unapojitolea kwa bwana, ujenzi wa mradi huanza.
Uzinduzi wa majaribio ya kiotomatiki
Mkutano ni mzuri, lakini kwa kweli, mradi unaweza kukusanyika kwa usalama, lakini haufanyi kazi. Kwa hiyo, hatua inayofuata ni automatisering ya mtihani. Kwa kuongeza, ni rahisi kabisa kuangalia matokeo ya kupita vipimo wakati unafanya ukaguzi wa PR - unajua kwa hakika kwamba vipimo vinapita na hakuna mtu aliyesahau kuendesha tawi lake kabla ya kuunganisha.
Tutaendesha vipimo wakati wa kuunda ombi la kuvuta na kuunganisha kwenye bwana, na wakati huo huo tutaongeza uundaji wa ripoti juu ya chanjo ya msimbo.
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 }}
Ili kufunika majaribio, mimi hutumia codecov kwa kushirikiana na programu-jalizi ya jacoco. codecov ina hatua yake mwenyewe, lakini inahitaji ishara kufanya kazi na ombi letu la kuvuta:
${{ secrets.CODECOV_TOKEN }} - tutaona ujenzi huu zaidi ya mara moja, siri ni utaratibu wa kuhifadhi siri katika GitHub, tunaweza kuandika huko nywila/tokens/hosts/urls na data zingine ambazo hazipaswi kujumuishwa kwenye msingi wa nambari ya kumbukumbu.
Unaweza kuongeza kutofautisha kwa siri katika mipangilio ya hazina kwenye GitHub:
Unaweza kupata ishara kwa Baada ya idhini kupitia GitHub, ili kuongeza mradi wa umma unahitaji tu kufuata kiunga kama hiki: /[repo name]. Hifadhi ya kibinafsi pia inaweza kuongezwa; ili kufanya hivi, unahitaji kutoa haki za codecov kwa programu katika Github.
Ongeza programu-jalizi ya jacoco kwenye faili ya 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>
Sasa codecov bot itaingiza kila ombi letu la kuvuta na kuongeza grafu ya mabadiliko ya chanjo:
Hebu tuongeze analyzer tuli
Katika miradi yangu mingi ya chanzo wazi mimi hutumia wingu la sonar kwa uchanganuzi wa nambari tuli, ni rahisi sana kuunganishwa na travis-ci. Kwa hivyo ni hatua ya kimantiki wakati wa kuhamia Vitendo vya GitHub kufanya vivyo hivyo. Soko la vitendo ni jambo la kupendeza, lakini wakati huu liliniacha kidogo, kwa sababu kutokana na mazoea nilipata hatua niliyohitaji na kuiongeza kwenye mtiririko wa kazi. Lakini iliibuka kuwa sonar haiungi mkono kufanya kazi kupitia hatua ya kuchambua miradi kwenye maven au gradle. Kwa kweli, hii imeandikwa katika nyaraka, lakini ni nani anayeisoma?!
Haiwezekani kupitia kitendo, kwa hivyo tutafanya kupitia programu-jalizi ya 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 - inaweza kupatikana kwa na unahitaji kuisajili kwa siri. GITHUB_TOKEN - hii ni ishara iliyojengwa ndani ambayo GitHub hutoa, kwa msaada wa sonarcloud[bot] itaweza kuingia kwenye Git ili kutuachia ujumbe katika maombi ya kuvuta.
Dsonar.projectKey - jina la mradi katika sonar, unaweza kuiona katika mipangilio ya mradi.
Shirika.Dsonar - jina la shirika kutoka GitHub.
Tunafanya ombi la kuvuta na kusubiri sonarcloud[bot] kuja katika maoni:
Usimamizi wa kutolewa
Muundo umesanidiwa, majaribio yametekelezwa, na tunaweza kutoa toleo. Wacha tuangalie jinsi Vitendo vya GitHub vinaweza kufanya usimamizi wa toleo kuwa rahisi zaidi.
Kazini, nina miradi ambayo msingi wake wa kificho uko kwenye bitbucket (kila kitu ni kama katika hadithi hiyo "Ninaandika kwa bitbucket wakati wa mchana, kujitolea kwa GitHub usiku"). Kwa bahati mbaya, bitbucket haina zana za usimamizi wa kutolewa zilizojumuishwa. Hili ni tatizo, kwa sababu kwa kila toleo unapaswa kuunda ukurasa kwa kuunganishwa na kutupa vipengele vyote vilivyojumuishwa katika kutolewa huko, tafuta kupitia majumba ya akili, kazi katika jira, kazi katika hifadhi. Kuna nafasi nyingi za kufanya makosa, unaweza kusahau kitu au kuingiza kitu ambacho tayari kilitolewa mara ya mwisho, wakati mwingine haijulikani wazi ni nini cha kuainisha ombi la kuvuta kama - ni kipengele au urekebishaji wa hitilafu, au majaribio ya kuhariri, au kitu cha miundombinu.
Vitendo vya GitHub vinawezaje kutusaidia? Kuna hatua nzuri - rasimu ya kutolewa, hukuruhusu kuweka kiolezo cha faili ya madokezo ya kutolewa ili kusanidi kategoria za maombi ya kuvuta na kuzipanga kiotomatiki katika faili ya madokezo ya toleo:
Mfano wa kiolezo cha kusanidi ripoti (.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
Ongeza hati ili kutoa rasimu (.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 }}
Maombi yote ya kuvuta kuanzia sasa yatakusanywa katika maelezo ya kutolewa kiotomatiki - uchawi!
Hapa swali linaweza kutokea: vipi ikiwa watengenezaji husahau kuweka vitambulisho kwenye PR? Kisha haijulikani ni aina gani ya kuiweka, na tena utalazimika kukabiliana nayo kwa mikono, na kila PR tofauti. Ili kurekebisha tatizo hili, tunaweza kutumia hatua nyingine - kithibitishaji cha lebo - inakagua uwepo wa vitambulisho kwenye ombi la kuvuta. Ikiwa hakuna vitambulisho vinavyohitajika, basi hundi itashindwa na tutaona ujumbe kuhusu hili katika ombi letu la kuvuta.
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'
Sasa ombi lolote la kuvuta lazima liweke alama kwa mojawapo ya vitambulisho: aina:rekebisha, chapa:vipengele, chapa:hati, chapa:majaribio, chapa:usanidi.
Ufafanuzi wa otomatiki wa maombi ya kuvuta
Kwa kuwa tuligusia mada kama kazi bora na maombi ya kuvuta, inafaa kuzungumza juu ya kitendo kama vile kiweka lebo, huweka vitambulisho katika PR kulingana na faili ambazo zimebadilishwa. Kwa mfano, tunaweza kuweka alama kama [kujenga] ombi lolote la kuvuta ambalo lina mabadiliko kwenye saraka .github/workflow.
Kuiunganisha ni rahisi sana:
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 }}
Tunahitaji pia faili inayoelezea mawasiliano kati ya saraka za mradi na mada za ombi la kuvuta:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Sikufanikiwa kuoanisha kitendo ambacho huweka lebo kiotomatiki katika maombi ya kuvuta na kitendo cha kuangalia uwepo wa lebo zinazohitajika; lebo-match haitaki kuona lebo zilizoongezwa na roboti. Inaonekana rahisi kuandika kitendo chako mwenyewe ambacho kinachanganya hatua zote mbili. Lakini hata katika fomu hii ni rahisi kutumia, unahitaji kuchagua lebo kutoka kwenye orodha wakati wa kuunda ombi la kuvuta.
Ni wakati wa kupeleka
Nilijaribu chaguzi kadhaa za kupeleka kupitia Vitendo vya GitHub (kupitia ssh, kupitia scp, na kutumia docker-hub), na naweza kusema kwamba, uwezekano mkubwa, utapata njia ya kupakia binary kwenye seva, haijalishi bomba lako limepotoshwa. ni.
Nilipenda chaguo la kuweka miundombinu yote katika sehemu moja, kwa hivyo hebu tuangalie jinsi ya kupeleka kwa Vifurushi vya GitHub (hii ni hazina ya yaliyomo kwenye binary, npm, jar, docker).
Hati ya kuunda picha ya kizimbani na kuichapisha katika Vifurushi vya 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 }}"
Kwanza, tunahitaji kujenga faili ya JAR ya maombi yetu, baada ya hapo tunahesabu njia ya usajili wa docker ya GitHub na jina la picha yetu. Kuna hila chache hapa ambazo bado hatujakutana nazo:
- ujenzi kama: echo β::set-output name=NAME::VALUEβ hukuruhusu kuweka thamani ya kigezo katika hatua ya sasa, ili iweze kusomwa katika hatua nyingine zote.
- unaweza kupata thamani ya kigezo kilichowekwa katika hatua ya awali kupitia kitambulisho cha hatua hii: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Tofauti ya kawaida ya GITHUB_REPOSITORY huhifadhi jina la hazina na mmiliki wake ("mmiliki/repo-jina"). Ili kukata kila kitu kutoka kwa mstari huu isipokuwa jina la hazina, tutatumia syntax ya bash: ${GITHUB_REPOSITORY#*/}
Ifuatayo tunahitaji kuunda picha ya kizimbani:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Ingia kwenye Usajili:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Na uchapishe picha hiyo kwenye Hifadhi ya Vifurushi vya GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Ili kuashiria toleo la picha, tunatumia nambari za kwanza kutoka kwa SHA hash ya ahadi - GITHUB_SHA pia kuna nuances hapa, ikiwa utatengeneza muundo kama huo sio tu wakati wa kuunganishwa kuwa bwana, lakini pia kulingana na uundaji wa ombi la kuvuta. tukio, basi SHA inaweza isilingane na heshi tunayoona kwenye historia ya git, kwa sababu hatua ya kuchukua/kulipa hutengeneza heshi yake ya kipekee ili kuepusha vitendo vya kukatisha tamaa katika PR.
Ikiwa kila kitu kilifanyika vizuri, kisha kufungua sehemu ya vifurushi ( https://github.com/antkorwin/github-actions/packages ) kwenye hazina, utaona picha mpya ya docker:
Huko unaweza pia kuona orodha ya matoleo ya picha ya docker.
Yote iliyobaki ni kusanidi seva yetu kufanya kazi na Usajili huu na kuanzisha upya huduma. Labda nitazungumza juu ya jinsi ya kufanya hivyo kupitia systemd wakati mwingine.
Ufuatiliaji
Wacha tuangalie chaguo rahisi jinsi ya kufanya ukaguzi wa afya kwa programu yetu kwa kutumia Vitendo vya GitHub. Programu yetu ya uanzishaji ina kiendeshaji, kwa hivyo hatuhitaji hata kuandika API ili kuangalia hali yake; tayari tumefanya kila kitu kwa wavivu. Unahitaji tu kuvuta mwenyeji: 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"}
Tunachohitaji ni kuandika kazi ili kuangalia seva kwa kutumia cron, na ikiwa ghafla haijibu, basi tutatuma taarifa kupitia telegram.
Kwanza, hebu tuone jinsi ya kuendesha mtiririko wa kazi wa cron:
on:
schedule:
- cron: '*/5 * * * *'
Ni rahisi, siwezi hata kuamini kuwa katika Github unaweza kuunda matukio ambayo hayafai kwenye vijiti vya wavuti hata kidogo. Maelezo yako kwenye nyaraka:
Wacha tuangalie hali ya seva kwa mikono kupitia 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"
Kwanza, tunahifadhi kwa kutofautisha kile seva ilijibu ombi, katika hatua inayofuata tunaangalia kuwa hali iko UP na, ikiwa sivyo, basi tunatoka na hitilafu. Ikiwa unahitaji "kuzidiwa" hatua kwa mikono yako, basi toka 1 - silaha inayofaa.
- 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 }}
Tunatuma kwa telegramu ikiwa tu hatua ilishindwa katika hatua ya awali. Kutuma ujumbe tunatumia appleboy/telegram-action; unaweza kusoma kuhusu jinsi ya kupata tokeni ya roboti na kitambulisho cha gumzo kwenye hati:
Usisahau kuandika kwa siri kwenye Github: URL ya seva na ishara za bot ya telegraph.
Wimbo wa bonasi - JIRA kwa wavivu
Niliahidi kwamba tutarudi JIRA, na tumerudi. Mamia ya mara nimeona hali ya kusimama wakati wasanidi walitengeneza kipengele, wakaunganisha tawi, lakini wakasahau kuburuta suala hilo hadi JIRA. Kwa kweli, ikiwa haya yote yamefanywa katika sehemu moja, itakuwa rahisi, lakini kwa kweli tunaandika nambari kwenye IDE, unganisha matawi kwenye bitbucket au GitHub, na kisha buruta kazi kwenye Jira, kwa hili tunahitaji kufungua windows mpya. , wakati mwingine ingia tena na nk. Unapokumbuka kikamilifu kile unachohitaji kufanya baadaye, basi hakuna uhakika wa kufungua bodi tena. Matokeo yake, asubuhi katika kusimama unahitaji kutumia muda uppdatering ubao wa kazi.
GitHub itatusaidia pia na kazi hii ya kawaida; kwa kuanzia, tunaweza kuburuta masuala kiotomatiki hadi kwenye safu wima ya code_review tunapowasilisha ombi la kuvuta. Unachohitaji kufanya ni kufuata kusanyiko la kutaja tawi:
[ΠΈΠΌΡ ΠΏΡΠΎΠ΅ΠΊΡΠ°]-[Π½ΠΎΠΌΠ΅Ρ ΡΠ°ΡΠΊΠ°]-Π½Π°Π·Π²Π°Π½ΠΈΠ΅
kwa mfano, ikiwa ufunguo wa mradi "Vitendo vya GitHub" ni GA, basi GA-8-jira-bot inaweza kuwa tawi la kutekeleza kazi ya GA-8.
Kuunganishwa na JIRA hufanya kazi kupitia vitendo kutoka kwa Atlassian, sio kamili, lazima niseme kwamba baadhi yao hawakufanya kazi kwangu hata kidogo. Lakini tutajadili zile tu ambazo hakika zinafanya kazi na zinatumika kikamilifu.
Kwanza unahitaji kuingia kwa JIRA kwa kutumia hatua: 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 }}
Ili kufanya hivyo, unahitaji kupata ishara katika JIRA, jinsi ya kufanya hivyo imeelezewa hapa:
Tunatoa kitambulisho cha kazi kutoka kwa jina la tawi:
- 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}}
Ukitafuta kwenye soko la GitHub, unaweza kupata kitendo cha kazi hii, lakini ilibidi niandike kitu kimoja kwa kutumia grep kwa kutumia jina la tawi, kwa sababu hatua hii kutoka kwa Atlassian haikutaka kufanya kazi kwenye mradi wangu kwa njia yoyote. , ili kujua nini kilikuwa kibaya pale - muda mrefu zaidi kuliko kufanya kitu kimoja kwa mikono yako.
Kilichobaki ni kuhamisha kazi hadi kwenye safu wima ya "Mapitio ya Msimbo" wakati wa kuunda ombi la kuvuta:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Kuna hatua maalum kwa hili kwenye GitHub, inayohitaji ni kitambulisho cha suala kilichopatikana katika hatua ya awali na uidhinishaji katika JIRA ambao tulifanya hapo juu.
Kwa njia hiyo hiyo, unaweza kuburuta kazi wakati wa kuunganisha kwenye bwana, na matukio mengine kutoka kwa mtiririko wa kazi wa GitHub. Kwa ujumla, yote inategemea mawazo yako na hamu ya kurekebisha michakato ya kawaida.
Matokeo
Ukiangalia mchoro wa kawaida wa DEVOPS, tumeshughulikia hatua zote, isipokuwa labda kufanya kazi, nadhani ukijaribu, unaweza kupata hatua fulani sokoni kwa kuunganishwa na mfumo wa dawati la usaidizi, kwa hivyo tutafikiria kuwa bomba limegeuka. kuwa kamili na hitimisho linaweza kutolewa kulingana na matumizi yake.
Faida:
- Soko na vitendo vilivyotengenezwa tayari kwa hafla zote, hii ni nzuri sana. Katika nyingi zao, unaweza pia kuangalia msimbo wa chanzo ili kuelewa jinsi ya kutatua tatizo sawa au kutuma ombi la kipengele kwa mwandishi moja kwa moja kwenye hazina ya GitHub.
- Kuchagua jukwaa lengwa la kusanyiko: Linux, mac os, windows ni kipengele cha kuvutia sana.
- Vifurushi vya Github ni jambo zuri, ni rahisi kuweka miundombinu yote mahali pamoja, sio lazima upite kupitia windows tofauti, kila kitu kiko ndani ya eneo la kubofya moja au mbili za panya na imeunganishwa kikamilifu na Vitendo vya GitHub. Msaada wa Usajili wa Docker katika toleo la bure pia ni faida nzuri.
- GitHub huficha siri katika magogo ya ujenzi, kwa hivyo kuitumia kuhifadhi nywila na ishara sio ya kutisha. Wakati wa majaribio yangu yote, sikuwahi kuona siri katika hali yake safi kwenye koni.
- Bila malipo kwa miradi ya Open Source
Minus:
- YML, sawa, simpendi. Wakati wa kufanya kazi na mtiririko kama huo, ujumbe wa kawaida wa ahadi nilionao ni "rekebisha umbizo la yml", kisha unasahau kuweka kichupo mahali pengine, au ukiandika kwenye mstari mbaya. Kwa ujumla, kukaa mbele ya skrini na protractor na mtawala sio uzoefu wa kupendeza zaidi.
- KUTATUA, kutatua mtiririko na ahadi, kujenga upya, na kutoa kwa koni sio rahisi kila wakati, lakini ni zaidi ya kitengo cha "umezidi"; umezoea kufanya kazi na IDEA inayofaa, wakati unaweza kurekebisha chochote. .
- Unaweza kuandika kitendo chako kwa kitu chochote ikiwa utaifunga kwa Docker, lakini ni javascript pekee inayoungwa mkono asili, kwa kweli hili ni suala la ladha, lakini ningependelea kitu kingine badala ya js.
Acha nikukumbushe kuwa hazina iliyo na maandishi yote iko hapa:
Wiki ijayo nitafanya na kwenye mkutano wa Heisenbug 2020 Piter. Sitakuambia tu jinsi ya kuepuka makosa wakati wa kuandaa data ya mtihani, lakini pia ushiriki siri zangu za kufanya kazi na seti za data katika programu za Java!
Chanzo: mapenzi.com