Minun on usein rakennettava putki rakennusprojekteja varten Javassa. Joskus se on avoimen lähdekoodin, joskus ei. Päätin äskettäin yrittää siirtää joitakin repojani Travis-CI:stä ja TeamCitystä GitHub Actionsiin, ja tämä tuli siitä.
Mitä automatisoimme?
Ensin tarvitsemme projektin, jonka automatisoimme, tehdään pieni sovellus Spring bootissa / Java 11 / Mavenissa. Tämän artikkelin kannalta sovelluslogiikka ei kiinnosta meitä ollenkaan, vaan sovellusta ympäröivä infrastruktuuri on meille tärkeä, joten meille riittää yksinkertainen REST API -ohjain.
Voit katsoa lähteet täältä: Kaikki putkilinjan rakentamisen vaiheet näkyvät tämän projektin vetopyynnöissä.
JIRA ja suunnittelu
On syytä sanoa, että käytämme yleensä JIRAa ongelmanseurantana, joten luodaan tälle projektille erillinen taulu ja lisätään ensimmäiset ongelmat sinne:
Hieman myöhemmin palaamme siihen, mitä mielenkiintoista JIRA ja GitHub voivat yhdessä tarjota.
Automatisoimme projektin kokoonpanon
Testiprojektimme on rakennettu mavenin kautta, joten sen rakentaminen on melko yksinkertaista, tarvitsemme vain mvn clean -paketin.
Tämän tekemiseksi Github Actionsin avulla meidän on luotava arkistoon tiedosto, joka kuvaa työnkulkuamme, tämä voidaan tehdä tavallisella yml-tiedostolla, en voi sanoa, että pidän "yml-ohjelmoinnista", mutta mitä voimme tehdä? teemme sen .github/-hakemistossa workflow/-tiedostossa build.yml, jossa kuvataan toiminnot päähaaraa rakennettaessa:
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 — Tämä on kuvaus tapahtumasta, jossa käsikirjoituksemme käynnistetään.
päällä: pull_request/push — ilmaisee, että tämä työnkulku on käynnistettävä joka kerta, kun isäntäkoneelle tehdään push ja vetopyyntöjä luodaan.
Seuraavassa on kuvaus tehtävistä (työpaikat) ja suoritusvaiheet (vaiheet) jokaiselle tehtävälle.
käy - Täällä voimme valita kohdekäyttöjärjestelmän, yllättäen voit valita jopa Mac OS: n, mutta yksityisissä arkistoissa tämä on melko kallista (verrattuna Linuxiin).
käyttötarkoituksiin mahdollistaa muiden toimintojen uudelleenkäytön, esimerkiksi Asennamme Java 11:n ympäristön käyttämällä toimintoa/setup-java-toimintoa.
Keinoin with voimme määrittää parametrit, joilla käynnistämme toiminnon, pohjimmiltaan nämä ovat argumentteja, jotka välitetään toiminnolle.
Jäljelle jää vain suorittaa projektin rakentaminen Mavenin kanssa: run: mvn -B clean package lippu -B sanoo, että tarvitsemme ei-interaktiivisen tilan, jotta maven ei yhtäkkiä halua kysyä meiltä jotain
Loistava! Nyt aina, kun sitoudut masteriin, projektin rakentaminen alkaa.
Testien käynnistysten automatisointi
Kokoaminen on hyvää, mutta todellisuudessa projekti voidaan koota turvallisesti, mutta ei toimi. Siksi seuraava askel on automatisoida testiajot. Lisäksi on varsin kätevää katsoa testien läpäisytuloksia, kun teet PR-arvioinnin - tiedät varmasti, että testit läpäisevät, eikä kukaan unohtanut suorittaa haaraansa ennen yhdistämistä.
Suoritamme testejä laadittaessa vetopyyntöä ja yhdistämme masteriin ja samalla lisäämme koodin peittävyyden raportin luomisen.
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 }}
Testien kattamiseksi käytän codecovia jacoco-laajennuksen yhteydessä. codecovilla on oma toimintonsa, mutta se tarvitsee tunnuksen toimiakseen vetopyyntömme kanssa:
${{ secrets.CODECOV_TOKEN }} — tulemme näkemään tämän rakenteen useammin kuin kerran, Secrets on mekanismi salaisuuksien tallentamiseksi GitHubiin, voimme kirjoittaa sinne salasanoja/tunnuksia/isäntiä/url-osoitteita ja muita tietoja, joita ei pitäisi sisällyttää arkiston koodikantaan.
Voit lisätä muuttujan salaisuuksiin GitHubin arkiston asetuksissa:
Voit saada tunnuksen osoitteessa GitHubin kautta tehdyn valtuutuksen jälkeen julkisen projektin lisäämiseksi sinun tarvitsee vain seurata tällaista linkkiä: /[repon nimi]. Voidaan myös lisätä yksityinen arkisto; tätä varten sinun on annettava Codecov-oikeudet sovellukselle Githubissa.
Lisää jacoco-laajennus POM-tiedostoon:
<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>
Nyt codecov-botti syöttää jokaisen vetopyyntömme ja lisää kattavuuden muutoskaavion:
Lisätään staattinen analysaattori
Useimmissa avoimen lähdekoodin projekteissani käytän kaikuluotainpilviä staattiseen koodin analysointiin, travis-ci:iin on melko helppo yhdistää. Joten se on looginen vaihe, kun siirryt GitHub Actionsiin tehdäksesi samoin. Toimintamarkkinat on hieno asia, mutta tällä kertaa se petti minut hieman, koska tottumuksesta löysin tarvitsemani toiminnan ja lisäsin sen työnkulkuun. Mutta kävi ilmi, että kaikuluotain ei tue projektien analysointia Mavenissa tai Gradlessa. Tietysti tämä on kirjoitettu dokumentaatioon, mutta kuka sitä lukee?!
Se ei ole mahdollista toiminnon kautta, joten teemme sen mvn-laajennuksen kautta:
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 - saa osoitteesta ja sinun on rekisteröitävä se salaisuuksiin. GITHUB_TOKEN - Tämä on GitHubin luoma sisäänrakennettu token, jonka avulla sonarcloud[bot] voi kirjautua sisään Gitiin jättääkseen meille viestejä vetopyynnöissä.
Dsonar.projectKey — projektin nimi kaikuluotaimessa, näet sen projektiasetuksista.
Dsonar.organisation - organisaation nimi GitHubista.
Teemme vetopyynnön ja odotamme, että sonarcloud[bot] tulee kommentteihin:
Release hallinta
Rakennus on konfiguroitu, testit ajettu ja julkaisu voidaan tehdä. Katsotaanpa, kuinka GitHub Actions voi tehdä julkaisujen hallinnasta paljon helpompaa.
Minulla on töissä projekteja, joiden koodikanta on bitbucketissa (kaikki on kuin siinä tarinassa "kirjoitan bitbucketiin päivällä, sitoudun GitHubiin yöllä"). Valitettavasti bitbucketissa ei ole sisäänrakennettuja julkaisunhallintatyökaluja. Tämä on ongelma, koska jokaiselle julkaisulle täytyy manuaalisesti luoda sivu konfluenssissa ja heittää sinne kaikki julkaisuun sisältyvät ominaisuudet, etsiä mielen palatseja, tehtäviä jirassa, sitoumuksia arkistossa. On monia mahdollisuuksia tehdä virhe, voit unohtaa jotain tai syöttää jotain, joka on jo julkaistu viimeksi, joskus ei yksinkertaisesti ole selvää, mihin vetopyyntö luokitellaan - onko se ominaisuus vai virheenkorjaus vai testien muokkaus, tai jotain infrastruktuuria.
Kuinka GitHub-toiminnot voivat auttaa meitä? Siinä on loistava toiminta - julkaisuluonnos, jonka avulla voit määrittää julkaisutietotiedostomallin vetopyyntöjen luokkien määrittämiseksi ja ryhmitellä ne automaattisesti julkaisutietotiedostoon:
Esimerkkimalli raportin luomista varten (.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
Lisää skripti julkaisuluonnoksen luomiseksi (.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 }}
Kaikki vetopyynnöt kerätään tästä lähtien julkaisutietoihin automaattisesti - taikuutta!
Tässä saattaa herää kysymys: entä jos kehittäjät unohtavat laittaa tunnisteet PR:ään? Sitten ei ole selvää, mihin luokkaan se laitetaan, ja taas joudut käsittelemään sitä manuaalisesti jokaisen PR:n kanssa erikseen. Tämän ongelman korjaamiseksi voimme käyttää toista toimintoa - etiketin vahvistajaa - se tarkistaa, onko vetopyynnössä tunnisteita. Jos vaadittuja tunnisteita ei ole, tarkistus epäonnistuu ja näemme tätä koskevan viestin vetopyynnössämme.
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'
Nyt kaikki vetopyynnöt on merkittävä jollakin tunnisteista: type:fix, type:features, type:documentation, type:tests, type:config.
Vetopyyntöjen automaattinen huomautus
Koska käsittelimme sellaista aihetta kuin tehokas työ vetopyyntöjen kanssa, kannattaa puhua sellaisesta toiminnasta kuin labeler, se laittaa tageja PR:ään sen perusteella, mitä tiedostoja on muutettu. Voimme esimerkiksi merkitä [buildiksi] minkä tahansa vetopyynnön, joka sisältää muutoksia hakemistoon .github/workflow.
Sen yhdistäminen on melko yksinkertaista:
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 }}
Tarvitsemme myös tiedoston, joka kuvaa projektihakemistojen ja vetopyyntöaiheiden välistä vastaavuutta:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
En onnistunut yhdistämään toimintoa, joka asettaa automaattisesti tunnisteet vetopyyntöihin, toimintoon, joka tarkistaa vaadittujen tunnisteiden olemassaolon; match-label ei halua nähdä botin lisäämiä tunnisteita. Vaikuttaa helpommalta kirjoittaa oma toimintasi, joka yhdistää molemmat vaiheet. Mutta jopa tässä muodossa se on melko kätevä käyttää; sinun on valittava luettelosta tarra luodessasi vetopyyntöä.
On aika ottaa käyttöön
Kokeilin useita käyttöönottovaihtoehtoja GitHub Actionsin kautta (ssh:n kautta, scp:n kautta ja docker-hubin avulla), ja voin sanoa, että todennäköisesti löydät tavan ladata binaari palvelimelle riippumatta siitä kuinka vino putkilinjasi On.
Pidin mahdollisuudesta pitää koko infrastruktuuri yhdessä paikassa, joten katsotaanpa, kuinka käyttöönotto GitHub-paketteihin (tämä on binaarisisällön, npm:n, jar:n, dockerin arkisto).
Komentosarja Docker-kuvan luomiseen ja sen julkaisemiseen GitHub-paketeissa:
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 }}"
Ensin meidän on rakennettava sovelluksemme JAR-tiedosto, jonka jälkeen laskemme polun GitHub Docker -rekisteriin ja kuvamme nimen. Tässä on muutamia temppuja, joihin emme ole vielä törmänneet:
- rakenne, kuten: echo “::set-output name=NAME::ARVO” mahdollistaa muuttujan arvon asettamisen nykyisessä vaiheessa, jotta se voidaan lukea kaikissa muissa vaiheissa.
- saat edellisessä vaiheessa asetetun muuttujan arvon tämän vaiheen tunnisteen kautta: ${{ steps.global_env.outputs.DOKERHUB_IMAGE_NAME }}
- Vakiomuuttuja GITHUB_REPOSITORY tallentaa arkiston nimen ja sen omistajan ("owner/repo-name"). Leikkaaksemme kaiken tältä riviltä paitsi arkiston nimen, käytämme bash-syntaksia: ${GITHUB_REPOSITORY#*/}
Seuraavaksi meidän on rakennettava telakointikuva:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Kirjaudu sisään rekisteriin:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Ja julkaise kuva GitHub Packages -tietovarastoon:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Kuvan version ilmaisemiseksi käytämme commitin SHA-hashista ensimmäisiä numeroita - GITHUB_SHA, tässä on myös vivahteita, jos teet sellaisia koonnoksia ei vain yhdistäessäsi masteriin, vaan myös vetopyynnön luomisen mukaan tapahtumassa, SHA ei välttämättä vastaa git-historiassa näkemäämme tiivistettä, koska toiminnot/kirjautumistoiminto tekee oman ainutlaatuisen tiivisteensä PR:n lukkiutumisen välttämiseksi.
Jos kaikki toimi hyvin, avaamalla paketit-osion (https://github.com/antkorwin/github-actions/packages) arkistossa, näet uuden telakointikuvan:
Siellä voit myös nähdä luettelon telakointikuvan versioista.
Jäljelle jää vain määrittää palvelimemme toimimaan tämän rekisterin kanssa ja käynnistää palvelu uudelleen. Todennäköisesti puhun siitä, kuinka tämä tehdään systemd:n kautta toisella kertaa.
seuranta
Katsotaanpa yksinkertaista vaihtoehtoa sovelluksemme kuntotarkastuksen suorittamiseksi GitHub Actionsin avulla. Käynnistyssovelluksessamme on toimilaite, joten meidän ei tarvitse edes kirjoittaa APIa tarkistaaksemme sen tilan; olemme jo tehneet kaiken laiskoille. Sinun tarvitsee vain vetää isäntä: 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"}
Tarvitsemme vain tehtävän palvelimen tarkistamiseksi cronilla, ja jos se ei yhtäkkiä vastaa meille, lähetämme ilmoituksen sähkeenä.
Selvitetään ensin, kuinka cron-työnkulku suoritetaan:
on:
schedule:
- cron: '*/5 * * * *'
Se on yksinkertaista, en voi edes uskoa, että Githubissa voit luoda tapahtumia, jotka eivät sovi webhookeihin ollenkaan. Yksityiskohdat löytyvät dokumentaatiosta:
Tarkistetaan palvelimen tila manuaalisesti curlilla:
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"
Tallennamme ensin muuttujaan, mitä palvelin vastasi pyyntöön, seuraavassa vaiheessa tarkistamme, että tila on UP ja jos näin ei ole, poistumme virheestä. Jos sinun täytyy "kuormittaa" toiminta käsilläsi, niin poistu 1 - sopiva ase.
- 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 }}
Lähetämme sähkeeseen vain, jos toiminto epäonnistui edellisessä vaiheessa. Viestin lähettämiseen käytämme appleboy/telegram-actionia; voit lukea bot-tunnuksen ja chat-tunnuksen hankkimisesta dokumentaatiosta:
Älä unohda kirjoittaa salaisuuksia Githubiin: palvelimen URL-osoite ja sähkebotin tunnukset.
Bonusraita - JIRA laiskoille
Lupasin, että palaamme JIRAan, ja olemme palanneet. Olen satoja kertoja havainnut stand-upissa tilanteen, jossa kehittäjät tekivät ominaisuuden, yhdistivät haaran, mutta unohtivat vetää ongelman JIRAan. Tietysti, jos kaikki tämä tehtiin yhdessä paikassa, se olisi helpompaa, mutta itse asiassa kirjoitamme koodia IDE:hen, yhdistämme haarat bitbucketiin tai GitHubiin ja vedämme sitten tehtävät Jiraan, tätä varten meidän on avattava uudet ikkunat , joskus kirjaudu sisään uudelleen jne. Kun muistat täydellisesti, mitä sinun on tehtävä seuraavaksi, ei ole mitään järkeä avata taulua uudelleen. Seurauksena on, että aamulla standupissa sinun täytyy viettää aikaa tehtävätaulun päivittämiseen.
GitHub auttaa meitä myös tässä rutiinitehtävässä; aluksi voimme vetää ongelmat automaattisesti code_review-sarakkeeseen, kun lähetämme vetopyynnön. Sinun tarvitsee vain noudattaa haaran nimeämiskäytäntöä:
[имя проекта]-[номер таска]-название
esimerkiksi jos projektiavain "GitHub Actions" on GA, niin GA-8-jira-bot voisi olla haara GA-8-tehtävän toteuttamiselle.
Integrointi JIRAn kanssa toimii Atlassianin toimien kautta, ne eivät ole täydellisiä, minun on sanottava, että jotkut niistä eivät toimineet minulle ollenkaan. Mutta keskustelemme vain niistä, jotka varmasti toimivat ja joita käytetään aktiivisesti.
Ensin sinun on kirjauduttava sisään JIRAan toiminnolla: 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 }}
Tätä varten sinun on hankittava merkki JIRAsta, kuinka tämä tehdään täällä:
Poimimme tehtävätunnisteen haaran nimestä:
- 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}}
Jos etsit GitHub-markkinapaikasta, löydät toiminnon tähän tehtävään, mutta minun piti kirjoittaa sama asia grepillä haaran nimellä, koska tämä Atlassianin toiminto ei halunnut toimia projektissani millään tavalla , selvittää, mikä siellä oli vialla - kauemmin kuin tehdä saman asian käsin.
Jäljelle jää vain siirtää tehtävä "Kooditarkistus" -sarakkeeseen luotaessa vetopyyntö:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Tätä varten GitHubissa on erityinen toimenpide, se tarvitsee vain edellisessä vaiheessa saadun ongelman tunnuksen ja JIRA:n valtuutuksen, jonka teimme yllä.
Samalla tavalla voit vetää tehtäviä yhdistäessäsi pääsovellukseen ja muita tapahtumia GitHub-työnkulusta. Yleensä kaikki riippuu mielikuvituksestasi ja halusta automatisoida rutiiniprosesseja.
Tulokset
Jos katsot klassista DEVOPS-kaaviota, olemme kattaneet kaikki vaiheet, paitsi ehkä toiminta, luulen, että jos yrität, voit löytää markkinoilta toimintaa helpdesk-järjestelmän integroimiseksi, joten oletamme, että putkisto kääntyi perusteellisena ja sen käytön perusteella voidaan tehdä johtopäätöksiä.
Plussat:
- Marketplace, jossa on valmiita toimintoja kaikkiin tilanteisiin, tämä on erittäin siistiä. Useimmissa niistä voit myös tarkastella lähdekoodia ymmärtääksesi, kuinka ratkaista samanlainen ongelma, tai lähettää ominaisuuspyynnön tekijälle suoraan GitHub-arkistoon.
- Kohdealustan valitseminen kokoonpanoa varten: Linux, mac os, windows on varsin mielenkiintoinen ominaisuus.
- Github Packages on hieno asia, on kätevää pitää koko infrastruktuuri yhdessä paikassa, sinun ei tarvitse surffata eri ikkunoiden läpi, kaikki on yhden tai kahden hiiren napsautuksen säteellä ja on täydellisesti integroitu GitHub Actionsin kanssa. Docker-rekisterituki ilmaisessa versiossa on myös hyvä etu.
- GitHub piilottaa salaisuudet rakennuslokeihin, joten sen käyttäminen salasanojen ja tunnuksien tallentamiseen ei ole niin pelottavaa. Kaikkien kokeideni aikana en koskaan voinut nähdä salaisuutta puhtaassa muodossaan konsolissa.
- Ilmainen avoimen lähdekoodin projekteille
Miinukset:
- YML, no, en pidä hänestä. Tällaisen vuon kanssa työskennellessäni yleisin commit-viesti on ”fix yml format”, joskus unohdat laittaa välilehden johonkin, joskus kirjoitat sen väärälle riville. Yleensä näytön edessä istuminen astelevyn ja viivaimen kanssa ei ole miellyttävin kokemus.
- DEBUG, kulun virheenkorjaus committeilla, uudelleenmuodostuksen suorittaminen ja tulostaminen konsoliin ei ole aina kätevää, mutta se on enemmän "olet ylikypsä" -kategoriaa; olet tottunut työskentelemään kätevän IDEA:n kanssa, kun voit korjata mitä tahansa. .
- Voit kirjoittaa toimintosi mihin tahansa, jos käärit sen Dockeriin, mutta vain javascript on natiivisti tuettu, tämä on tietysti makuasia, mutta mieluummin jotain muuta js:n sijaan.
Muistutan teitä siitä, että arkisto kaikkine komentosarjoineen on täällä:
Ensi viikolla aion esiintyä Heisenbug 2020 Piter -konferenssissa. Kerron sinulle paitsi kuinka välttää virheitä valmisteltaessa testitietoja, myös jaan salaisuuteni Java-sovellusten tietojoukkojen kanssa työskentelystä!
Lähde: will.com