Ellē ar GitHub Actions (veidojot CI/CD pipeline Java projektam)

Man bieži jāveido pipeline savu projektu veidošanai Java valodā. Dažreiz tie ir atvērtā koda, dažreiz ne. Nesen es nolēmu izmēģināt pārvietot dažus savus repozitorijus no Travis-CI un TeamCity uz GitHub Actions, un lūk, kas no tā iznāca.

Ko automatizēsim

Sāksim ar projektu, ko mēs vēlamies automatizēt. Izveidosim nelielu lietotni uz Spring Boot / Java 11 / Maven. Šajā rakstā mūs neinteresēs lietojumprogrammas loģika, mums būtībā ir svarīga infrastruktūra ap lietotni, tāpēc mums pietiks ar vienkāršu REST API kontrolieri.

Avoti ir pieejami šeit: github.com/antkorwin/github-actions visi posmi pipeline konveijera izveidē ir atspoguļoti šī projekta pull pieprasījumos.

JIRA un plānošana

Jāatzīmē, ka mēs parasti izmantojam JIRA kā uzdevumu izsekošanas rīku, tāpēc uztaisīsim atsevišķu dēli šim projektam un pievienosim tur pirmos uzdevumus:

Nedaudz vēlāk mēs atgriezīsimies pie tā, ko interesantu var dot JIRA un GitHub kombinācija.

Automatizējam projekta veidošanu

Mūsu testa projekts tiek veidots ar Maven, tāpēc tā veidošana ir diezgan vienkārša, viss, kas mums nepieciešams, ir mvn clean package.

Lai to izdarītu, izmantojot GitHub Actions, mums būs jāizveido repositārijā fails ar mūsu workflow aprakstu. To var izdarīt ar parastu yml failu. Es nezinu, vai man patīk 'programmatūra yml', bet ko darīt — veidojam direktorijā .github/workflow/ failu build.yml, kurā aprakstīsim darbības, kas jāpaveic, veidojot master zaru:

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

jā — tas ir notikumu apraksts, pēc kura tiks palaižs mūsu skripts.

on: pull_request / push — norāda, ka šo workflow ir jāpalaiž katru reizi, kad tiek veikts push uz master un tiek izveidoti pull pieprasījumi.

Tālāk nāk uzdevumu apraksts (jobs) un izpildes soļi (steps) katram uzdevumam.

runs-on — šeit mēs varam izvēlēties mērķa operētājsistēmu, pārsteidzoši var izvēlēties pat Mac OS, bet uz privātiem repozitorijiem tas ir diezgan dārgs prieks (salīdzinot ar linux).

uses ļauj atkārtoti izmantot citus akcijas. Piemēram, ar akcijas actions/setup-java palīdzību mēs iedibinām vidi Java 11.

Izmantojot with Mēs varam norādīt parametrus, ar kuriem uzsākam darbību, būtībā tie ir argumenti, kas tiks nodoti akcijai.

Atliek tikai palaist Maven komandu, lai izveidotu projektu: run: mvn -B clean package ReadinessGate -B norāda, ka mums ir nepieciešams non-interactive mode, lai Maven nejautātu mums kaut ko.

Lieliski! Tagad, katru reizi, kad notiek sava veida apstiprināšana uz galvenā zara, tiks uzsākta projekta izveide.

Automatizējam testu izpildi.

Izveide ir labi, bet реālajā dzīvē projekts var veiksmīgi izveidoties, bet nedarboties. Tāpēc nākamais solis ir pievērsties testu automātiskai izpildei. Turklāt ir diezgan ērti skatīties testu izpildes rezultātus, veicot PR pārskatus — tu zini, ka testi ir izpildīti un neviens nav aizmirsis pirms iekļaušanas izpildīt savu zar.

Veiksim testu izpildi, kad tiek izveidots pull-request un tiek iekļauts galvenajā, un pievienosim arī kodēšanas pārklājuma ziņojuma veidošanu.

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 }}

Testu pārklājuma nodrošināšanai es izmantoju codecov kopā ar jacoco spraudni. Codecov ir sava darbība, bet, lai strādātu ar mūsu pull-request, ir nepieciešams tokens:

${{ secrets.CODECOV_TOKEN }} — šādu konstrukciju mēs satiksim vēl ne vienu reizi, secrets ir mehānisms noslēpumu uzglabāšanai GitHub, tur mēs varam norādīt paroli/tokenu/hostus/url un citus datus, kurus nevajadzētu atklāt kodu bāzē.

Pievienot mainīgo secrets var GitHub repozitorija iestatījumos:

Tokenu var iegūt adresē: codecov.io pēc autentifikācijas caur GitHub, lai pievienotu publisku projektu, ir vienkārši jāiziet cauri saitei ar šādu formu: GitHub lietotāja vārds/[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.

Pievienojam jacoco spraudni POM failam:

org.jacoco
	jacoco-maven-plugin
	0.8.4
	
		
			
				prepare-agent
			
		
		
		
			report
			test
			
				report
			
		
	


	org.apache.maven.plugins
	maven-surefire-plugin
	2.22.2
	
		plain
		
			**/*Test*.java
			**/*IT*.java

Tagad katrs mūsu pull request būs ar codecov bot, kas pievienos pārklājuma izmaiņu grafiku:

Pievienosim statisko analizatoru

Lielākajā daļā savu atvērto avotu projektu es izmantoju sonar cloud statiskai koda analīzei, to ir diezgan viegli pievienot travis-ci. Tādēļ tas ir loģisks solis, migrējot uz GitHub Actions, darīt to pašu. Action tirgus - foršs rīks, bet šoreiz tas nedaudz pievīla, jo es ierasti atradu vajadzīgo action un ierakstīju to workflow. Bet izrādījās, ka sonar neatbalsta darbību projektu analīzei, kas tiek veidoti ar maven vai gradle. Par to protams ir rakstīts dokumentācijā, bet kurš gan to lasa?!

Caur action to nevar, tāpēc darīsim caur 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 — var iegūt sonarcloud.io un tas jāieraksta secrets. GITHUB_TOKEN — tas ir iebūvēts tokens, ko ģenerē GitHub, ar tā palīdzību sonarcloud[bot] varēs autorizēties gitā, lai atstātu mums ziņojumus pull requestos.

Dsonar.projectKey — projekta nosaukums sonarā, ko var skatīt projekta iestatījumos.

Dsonar.organization — organizācijas nosaukums no GitHub.

Izveidojam pull request ungaidām, kad sonarcloud[bot] pievienos komentārus:

Izlaiduma vadība

Build ir konfigurēts, testi ir pabeigti, tagad varam veikt izlaidumu. Apskatīsim, kā GitHub Actions palīdz būtiski vienkāršot izlaiduma vadību.

Darba vietā man ir projekti, kuru koda bāze atrodas bitbucket (viss kā tajā stāstā «dienā rakstu bitbucket, naktī kommitēju GitHub»). Diemžēl bitbucket nav iebūvētu līdzekļu, lai pārvaldītu laidienus. Tā ir problēma, jo katram laidienam ir nepieciešams manuāli izveidot lapu confluence un ievietot tajā visus jaunievedumus, kas iekļauti laidienā, meklēt prāta koridoros, uzdevumos jira, kommitos repozitorijā. Ir daudz iespēju kļūdīties, var kaut ko aizmirst vai pierakstīt to, kas jau tika izlaists iepriekš, dažreiz vienkārši nav skaidrs, pie kā attiecināt kādu pull-request - vai tas ir jaunievedums vai kļūdu labojums, vai testu labošana, vai kaut kas infrastruktūras jautājums.

Kā mums var palīdzēt GitHub actions? Ir lielisks akcijas papildinājums - release drafter, kas ļauj noteikt laidiena piezīmju faila veidni, lai konfigurētu pull-request kategorijas un automātiski tās grupētu laidiena piezīmju failā:

Piemērs veidnei atskaitēm (.github/release-drafter.yml):

name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
  - title: ' Jaunas funkcijas'
    labels:
      - 'type:features'
# šajā kategorijā apkopojam visus PR ar atzīmi type:features

  - title: ' Kļūdu labojumi'
    labels:
      - 'type:fix'
# līdzīgi atzīmei type:fix un t.t.

  - title: ' Dokumentācija'
    labels:
      - 'type:documentation'

  - title: ' Konfigurācija'
    labels:
      - 'type:config'

change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
  ## Izmaiņas
  $CHANGES

Pievienojam skriptu, lai ģenerētu laidiena melnrakstu (.github/workflows/release-draft.yml):

name: "Izveidot melnraksta laidienu"

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 }}

Visi pull-requesti no šī brīža tiks automātiski apkopoti laidiena piezīmēs — maģija!

Šeit var rasties jautājums: kas notiks, ja izstrādātāji aizmirsīsit pievienot atzīmes PR? Tad nav skaidrs, kādā kategorijā to klasificēt, un atkal nāksies strādāt roku darbs, katru PR izskatot atsevišķi. Lai novērstu šo problēmu, varam izmantot vēl vienu akciju - label verifier - kas pārbauda, vai uz pull-request ir norādītas atzīmes. Ja nav nevienas obligātās atzīmes, tad pārbaude neizdosies, un mēs redzēsim ziņojumu par to mūsu pull-requestā.

name: "Pārbaudīt tipu atzīmes"

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'

Tagad katram pull-requestam jābūt atzīmētam ar vienu no šiem tagiem: type:fix, type:features, type:documentation, type:tests, type:config.

Automātiska piezīmju pievienošana pull pieprasījumiem

Tā kā mēs pieskārāmies tādai tēmai kā efektīva darbība ar pull pieprasījumiem, ir vērts pieminēt arī tādu rīku kā labeler, kas pievieno atzīmes PR, pamatojoties uz to, kuri faili tika mainīti. Piemēram, mēs varam atzīmēt kā [build] jebkuru pull pieprasījumu, kurā ir izmaiņas direktorijā .github/workflow.

To savienot ir samērā vienkārši:

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 }}

Vēl mums būs nepieciešama faila apraksts, kas atbilst projektu direktorijām un pull pieprasījumu tēmām:

theme:build:
  - ".github/**"
  - "pom.xml"
  - ".travis.yml"
  - ".gitignore"
  - "Dockerfile"

theme:code:
  - "src/main/*"

theme:tests:
  - "src/test/*"

theme:documentation:
  - "docs/**"

theme:TRASH:
  - ".idea/**"
  - "target/**"

Saskaņot darbību, kas automātiski pievieno atzīmes pull pieprasījumiem, un darbību, kas pārbauda obligāto atzīmju klātbūtni, man neizdevās, match-label kategoriski nevēlas atzīt botu pievienotās atzīmes. Izskatās, ka vienkāršāk būs uzrakstīt savu darbību, kas apvieno abus etapus. Taču pat šādā veidā tas ir diezgan ērti, ir jāizvēlas atzīme no saraksta, veidojot pull pieprasījumu.

Laiks izvietot

Es izmēģināju vairākas izvietošanas iespējas, izmantojot GitHub Actions (caur ssh, caur scp un ar docker-hub palīdzību), un varu teikt, ka, visticamāk, jūs atradīsiet veidu, kā augšupielādēt bināro failu serverī, kāds būtu jūsu pipeline neatkarīgi no tā, cik tas izklausās dīvaini.

Man patika iespēja turēt visu infrastruktūru vienā vietā, tāpēc aplūkosim, kā veikt izvietošanu GitHub Packages (tas ir repozitorijs binārajiem сontent, npm, jar, docker).

Docker attēla būves skripts un tā publicēšana GitHub Packages:

nosaukums: Izvietot docker attēlu

uz:
  spiediens:
    filiāles:
      - 'master'

darbi:

  būvēt_docker_attēlu:
    darbojas: ubuntu-18.04
    soļi:

#     Izveidot JAR:
      - izmanto: actions/checkout@v1
      - nosaukums: konfigurēt JDK 11
        izmanto: actions/setup-java@v1
        ar:
          java-version: 1.11
      - nosaukums: Maven Pakotne
        palaist: mvn -B clean compile package -DskipTests

#     Iestatīt globālās vides mainīgos:
      - nosaukums: iestatīt globālo vidi
        id: global_env
        palaist: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*\/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com\/${GITHUB_REPOSITORY}\/${GITHUB_REPOSITORY#*\/}"

#     Izveidot Docker attēlu:
      - nosaukums: Izveidot un marķēt attēlu
        palaist: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - nosaukums: Docker pieteikšanās
        palaist: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publicēt attēlu GitHub pakotņu datu bāzē:
      - nosaukums: Publicēt attēlu
        vide:
          IMAGE_NAME: $GITHUB_REPOSITORY
        palaist: docker push "docker.pkg.github.com\/$GITHUB_REPOSITORY\/${{ steps.global_env.outputs.IMAGE_NAME }}"

Vispirms mums ir jāsavāc mūsu lietojumprogrammas JAR fails, pēc tam mēs aprēķinām ceļu uz GitHub docker reģistru un mūsu attēla nosaukumu. Šeit ir dažas nianses, ar kurām mēs vēl neesam saskārušies:

• konstruēšana: echo «::set-output name=NAME::VALUE» ļauj iestatīt mainīgā vērtību pašreizējā solī, tā, lai to vēlāk varētu izlasīt visos pārējos soļos.
• iegūt mainīgā vērtību, ko iestatījis iepriekšējais solis, var, izmantojot šī soļa identifikatoru: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• Standarta mainīgajā GITHUB_REPOSITORY ir glabāts repo nosaukums un tā īpašnieks («owner/repo-name»). Lai izgrieztu no šīs virknes visu izņemot repo nosaukumu, izmantosim bash sintaksi: ${GITHUB_REPOSITORY#*\/}

Tālāk mums ir jāsavāc docker attēls:

docker build -t "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions:latest"

Autorizēties reģistrā:

docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

Un publicēt attēlu GitHub pakotņu datu bāzē:

docker push "docker.pkg.github.com\/antkorwin\/github-actions\/github-actions"

Lai norādītu attēla versiju, mēs izmantojam pirmos skaitļus no komite SHA-atslēgas — GITHUB_SHA, šeit arī ir nianses; ja jūs veiksiet šādus savākšanas procesus ne tikai pievienojot master, bet arī uz pull-request izveides notikumiem, tad SHA var nesakrist ar hash, ko redzam git vēsturē, jo actions/checkout veic savu unikālo hash, lai izvairītos no savstarpējām darbību bloķēšanām PR.

Ja viss izdevās, atverot pakotņu sadaļu (https://github.com/antkorwin/github-actions/packages) jūsu repozitorijā, jūs redzēsiet jauno docker attēlu:

Tur var apskatīt docker attēlu versiju sarakstu.

Pārējais ir tikai mūsu servera konfigurēšana darbam ar šo reģistru un pakalpojuma restartēšana. Par to, kā to izdarīt, izmantojot systemd, esmu pārliecināts, ka pastāstīšu citreiz.

Uzraudzība

Paskatīsimies vienu vienkāršu veidu, kā veikt mūsu lietotnes veselības pārbaudi, izmantojot GitHub Actions. Mūsu boot lietotnē ir actuator, tāpēc API tā stāvokļa pārbaudei nemaz nav jāraksta, slinkajiem viss jau ir izdarīts. Jūs tikai jāizsauc hosts: 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"}

Viss, kas mums nepieciešams, ir uzrakstīt uzdevumu servera pārbaudei pa kronu, un, ja tas nejauši mums neatbild, tad nosūtīsim paziņojumu uz telegramu.

Sāksim ar to, kā palaist workflow pa kronu:

on:
  schedule:
    - cron:  '*\/5 * * * *'

Visam ir vienkārši, pat neticami, ka GitHub var izveidot šādus notikumus, kas pilnīgi neiekļaujas webhook'os. Sīkāka informācija ir dokumentācijā: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Servera stāvokļa pārbaudi veiksim ar 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 "veselības pārbaude neizdevās"
            exit 1
          fi
          echo "Viss kārtībā"

Vispirms saglabājam mainīgajā to, ko atbildēja serveris uz pieprasījumu, nākamajā solī pārbaudām, vai statuss ir UP, un, ja tas tā nav, iznākam ar kļūdu. Ja nepieciešams manuāli 'nogalināt' darbību, tad exit 1 — piemērots ierocis.

  - name: send alert in telegram
    if: ${{ failure() }}
    uses: appleboy/telegram-action@master
    with:
      to: ${{ secrets.TELEGRAM_TO }}
      token: ${{ secrets.TELEGRAM_TOKEN }}
      message: |
        Veselības pārbaude:
        ${{secrets.SERVER_HOST}}/api/actuator/health
        neizdevās ar rezultātu:
        ${{ steps.ping.outputs.status }}

Paziņojumu uz telegramu sūtām tikai tad, ja darbība iepriekšējā solī neizdevās. Lai nosūtītu ziņojumu, izmantojam appleboy/telegram-action, kā iegūt bota tokenu un čata ID var izlasīt dokumentācijā: github.com/appleboy/telegram-action

Neaizmirstiet ievadīt GitHub slepenajos datos: URL serverim un tokenus telegrama botam.

Bonusa treks — JIRA slinkajiem

Es apsolīju, ka mēs atgriezīsimies pie JIRA, un mēs atgriezāmies. Simtiem reižu esmu novērojusi sapulcēs situāciju, kad izstrādātāji ir izveidojuši funkciju, apvienojuši filiāli, bet aizmirsuši pārvietot uzdevumu JIRA. Protams, ja viss tiktu darīts vienuviet, tas būtu vienkāršāk, bet faktiski mēs rakstām kodu IDE, apvienojam filiāles bitbucket vai GitHub, bet uzdevumus pēc tam pārvietojam uz JIRA, tam ir jāatver jaunas logi, dažreiz atkārtoti jāielogojas utt. Kad tu lieliski atceries, kas tālāk jādara, nav jēgas vēlreiz atvērt dēļus. Rezultātā no rīta sapulcē ir jātērē laiks uzdevumu dēļa aktualizēšanai.

GitHub mums palīdzēs arī šajā rutīnā, vispirms varam automātiski pārvietot uzdevumus uz kolonnas code_review, kad esam ievietojuši pull-request. Viss, kas nepieciešams, ir ievērot nosaukuma vienošanās filiālēm:

[projekta nosaukums]-[uzdevuma numurs]-nosaukums

piemēram, ja projekta atslēga «GitHub Actions» ir GA, tad GA-8-jira-bot varētu būt filiāle uzdevuma GA-8 izpildei.

Integrācija ar JIRA darbojas caur Atlassian darbībām, tās nav ideālas, jāsaka, ka dažas no tām man vispār nedarbojās. Bet mēs apspriedīsim tikai tās, kas noteikti strādā un tiek aktīvi izmantotas.

Vispirms jāiziet autorizācija JIRA, izmantojot darbību: 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 }}

Tam ir jāiegūst tokens JIRA, kā to izdarīt, ir rakstīts šeit: confluence.atlassian.com/cloud/api-tokens-938839638.html

Izvelkam uzdevuma identifikatoru no filiāles nosaukuma:

  - 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 "Lūdzu, nosauciet savu filiāli atbilstoši JIRA uzdevumam: [project_key]-[task_number]-branch_name"
        exit 1
      fi
      echo veiksmīgi atrasts JIRA uzdevums: ${{steps.find_issue.outputs.ISSUE_ID}}

Ja meklē GitHub tirgotavā, var atrast darbību šim uzdevumam, bet man bija jāuzraksta tas pats ar grep pēc filiāles nosaukuma, jo šī darbība no Atlassian negribēja darboties manā projektā, saprast, kur ir problēma, aizņemtu ilgāk nekā izdarīt to ar roku.

Atliek tikai pārvietot uzdevumu kolonnā „Code review”, veidojot pull request:

  - name: Pārvietot uzdevumu
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

Tam ir speciāla darbība GitHub, viss, kas tam nepieciešams, ir uzdevuma identifikators, kas iegūts iepriekšējā solī, un autentifikācija JIRA, ko mēs veicām iepriekš.

Tāpat var pārvietot uzdevumus, veicot merge uz master un citos GitHub workflow notikumos. Kopumā viss ir atkarīgs no jūsu iztēles un vēlēšanās automatizēt rutīnas procesus.

Secinājumi

Ja paskatās uz klasisko DEVOPS diagrammu, mēs esam aptvēruši visus posmus, izņemot operate. Domāju, ka, ja cenšas, var atrast kādu darbību tirgū, lai integrētos ar help-desk sistēmu, tādējādi varam uzskatīt, ka pipeline izdevās būt pamatīgs un, balstoties uz tā lietošanu, varam izdarīt secinājumus.

Priekšrocības:

• Tirgus vietne ar gatavām darbībām visām dzīves situācijām ir ļoti forša. Lielākajā daļā no tām var arī apskatīt avotus, lai saprastu, kā atrisināt līdzīgu uzdevumu vai tieši iekļaut funkcionalitātes pieprasījumu autoram GitHub repozitorijā.
• Mērķplatformas izvēle būvēšanai: Linux, Mac OS, Windows ir diezgan interesanta funkcija.
• GitHub Packages ir lieliska lieta, turēt visu infrastruktūru vienā vietā ir ērti, nav jāmeklē pa dažādām logiem, viss ir viena vai divu peles klikšķu attālumā un lieliski integrēts ar GitHub Actions. Docker registry atbalsts bezmaksas versijā ir arī labs ieguvums.
• GitHub slēpj slepenos datus būvēšanas žurnālos, tādēļ izmantot to paroles un tokenu uzglabāšanai nav tik biedējoši. Visa eksperimentos man nekad nav izdevies redzēt noslēpumu tīrā veidā konsolē.
• Bezmaksas Open Source projektiem

Mīnusi:

• YML, nu, man tas negaršo. Strādājot ar tādu plūsmu, mana visbiežākā commit ziņojuma ir „fix yml format”, vai nu aizmirsti kaut kur pielikt tabulatoru, vai nepareizajā rindā uzraksti. Kopumā sēdēt pie datora ar transportieri un lineālu nav pati patīkamākā nodarbe.
• DEBUG, plūsmu atkļūdošana ar commitiem, pārbūves uzsākšanu un izvadīšanu konsolē ne vienmēr ir ērti, bet tas vairāk ir no sērijas „jūs esat saraduši”, esat pieraduši strādāt ar ērtajām IDEA, kad var atkļūdot visu, kas vien ir.
• Savu darbību var uzrakstīt uz jebkuras platformas, ja to ietver Docker, taču nativously atbalsta tikai JavaScript. Protams, tas ir gaumes jautājums, bet es labprāt izvēlētos kaut ko citu vietā js.

Atgādinu, ka repozitorijs ar visiem skriptiem atrodas šeit: github.com/antkorwin/github-actions

Nākamnedēļ es uzstāšos ziņojums uz konferences Heisenbug 2020 Piter. Pastāstīšu ne tikai par to, kā izvairīties no kļūdām testēšanas datu sagatavošanā, bet arī dalīšos ar savām noslēpumainām metodēm datu komplektu apstrādē Java aplikācijās!

Avots: habr.com