Elles apļi ar GitHub Actions (CI/CD konveijera izveide Java projektam)

Man bieži ir jāveido cauruļvads būvniecības projektiem Java valodā. Dažreiz tas ir atvērts avots, dažreiz tas nav. Es nesen nolēmu mēģināt pārvietot dažus savus repozitorijus no Travis-CI un TeamCity uz GitHub Actions, un tas ir tas, kas no tā izriet.

Ko mēs automatizēsim?

Pirmkārt, mums ir nepieciešams projekts, kuru mēs automatizēsim, izveidosim nelielu lietojumprogrammu Spring boot / Java 11 / Maven. Šī raksta izpratnē mūs nemaz neinteresēs lietojumprogrammu loģika, mums ir svarīga infrastruktūra ap lietojumprogrammu, tāpēc mums pietiks ar vienkāršu REST API kontrolieri.

Avotus varat apskatīt šeit: github.com/antkorwin/github-actions Visi cauruļvada būvniecības posmi ir atspoguļoti šī projekta piesaistes pieprasījumos.

JIRA un plānošana

Ir vērts teikt, ka mēs parasti izmantojam JIRA kā problēmu izsekotāju, tāpēc izveidosim šim projektam atsevišķu dēli un pievienosim tur pirmās problēmas:

Nedaudz vēlāk atgriezīsimies pie tā, ko interesantu var piedāvāt JIRA un GitHub kombinācijā.

Mēs automatizējam projekta montāžu

Mūsu testa projekts ir izveidots, izmantojot maven, tāpēc tā izveidošana ir diezgan vienkārša, viss, kas mums nepieciešams, ir mvn clean pakotne.

Lai to izdarītu, izmantojot Github Actions, mums repozitorijā būs jāizveido fails, kas apraksta mūsu darbplūsmu, to var izdarīt ar parastu yml failu, es nevaru teikt, ka man patīk “yml programmēšana”, bet ko mēs varam darīt - mēs to darām .github/ direktorija darbplūsmas/ failā build.yml, kurā mēs aprakstīsim darbības, veidojot galveno filiāli:

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 — tas ir apraksts par notikumu, kurā tiks palaists mūsu scenārijs.

on: pull_request/push — norāda, ka šī darbplūsma ir jāpalaiž katru reizi, kad tiek veikts nosūtīšanas uz galveno ierīci un tiek izveidoti izvilkšanas pieprasījumi.

Tālāk ir sniegts uzdevumu apraksts (darba vietas) un izpildes soļi (pasākumi) katram uzdevumam.

uzskrien - šeit mēs varam izvēlēties mērķa OS, pārsteidzoši, jūs pat varat izvēlēties Mac OS, bet privātajās krātuvēs tas ir diezgan dārgi (salīdzinot ar Linux).

lietojumi ļauj atkārtoti izmantot citas darbības, piemēram, izmantojot darbību/setup-java darbību, mēs instalējam vidi Java 11.

Ar ar mēs varam norādīt parametrus, ar kuriem mēs uzsākam darbību, būtībā tie ir argumenti, kas tiks nodoti darbībai.

Atliek tikai palaist projekta veidošanu ar Maven: run: mvn -B clean package karogs -B saka, ka mums ir nepieciešams neinteraktīvs režīms, lai maven pēkšņi nevēlētos mums kaut ko jautāt

Lieliski! Tagad katru reizi, kad uzticaties meistaram, sākas projekta izveide.

Testu palaišanas automatizācija

Montāža ir laba, bet patiesībā projektu var droši salikt, bet nestrādāt. Tāpēc nākamais solis ir automatizēt testa darbības. Turklāt ir diezgan ērti aplūkot testu nokārtošanas rezultātus, veicot PR pārskatīšanu - jūs noteikti zināt, ka testi iztur, un neviens nav aizmirsis palaist savu filiāli pirms sapludināšanas.

Mēs veiksim testus, veidojot izvilkšanas pieprasījumu un apvienosim galveno, un tajā pašā laikā pievienosim atskaites izveidi par koda pārklājumu.

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

Lai aptvertu testus, es izmantoju codecov kopā ar spraudni jacoco. Codecov ir sava darbība, taču tai ir nepieciešams marķieris, lai tas darbotos ar mūsu vilkšanas pieprasījumu:

${{ secrets.CODECOV_TOKEN }} — šo konstrukciju redzēsim ne reizi vien, noslēpumi ir mehānisms noslēpumu glabāšanai GitHub, tur varam ierakstīt paroles/tokenus/hosts/url un citus datus, kurus nevajadzētu iekļaut repozitorija kodu bāzē.

Varat pievienot mainīgo noslēpumiem GitHub repozitorija iestatījumos:

Jūs varat saņemt žetonu plkst codecov.io Pēc autorizācijas caur GitHub, lai pievienotu publisku projektu, jums vienkārši jāievēro šāda saite: GitHub lietotājvārds/[repo nosaukums]. Var pievienot arī privātu repozitoriju; lai to izdarītu, Github lietojumprogrammai ir jāpiešķir kodeva tiesības.

Pievienojiet jacoco spraudni POM failam:

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

Tagad kodēšanas robots ievadīs katru mūsu izvilkšanas pieprasījumu un pievienos pārklājuma izmaiņu grafiku:

Pievienosim statisko analizatoru

Lielākajā daļā manu atvērtā koda projektu statiskā koda analīzei izmantoju sonāra mākoni, ir diezgan viegli izveidot savienojumu ar travis-ci. Tāpēc tas ir loģisks solis, migrējot uz GitHub Actions, lai veiktu to pašu. Akcijas tirgus ir forša lieta, taču šoreiz tas mani nedaudz pievīla, jo aiz ieraduma atradu vajadzīgo darbību un pievienoju to darbplūsmai. Taču izrādījās, ka hidrolokators neatbalsta darbību, lai analizētu projektus mavenā vai gradle. Protams, tas ir rakstīts dokumentācijā, bet kurš to lasa?!

Tas nav iespējams, izmantojot darbību, tāpēc mēs to darīsim, izmantojot spraudni 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 - var saņemt plkst sonarcloud.io un jums tas jāreģistrē noslēpumos. GITHUB_TOKEN - tas ir GitHub ģenerēts iebūvēts marķieris, ar kura palīdzību sonarcloud[bot] varēs pieteikties Git, lai atstātu mums ziņojumus pull pieprasījumos.

Dsonar.projectKey — projekta nosaukums sonārā, to var redzēt projekta iestatījumos.

Dsonārs.organizācija — organizācijas nosaukums no GitHub.

Mēs iesniedzam izvilkšanas pieprasījumu un gaidām, kad sonarcloud[bot] ieradīsies komentāros:

Atbrīvošanas vadība

Būvējums ir konfigurēts, testi ir izpildīti, un mēs varam veikt laidienu. Apskatīsim, kā GitHub Actions var ievērojami atvieglot laidienu pārvaldību.

Man darbā ir projekti, kuru koda bāze ir bitbucket (viss ir kā tajā stāstā “Dienas laikā rakstu uz bitbucket, naktī apņemos GitHub”). Diemžēl bitbucket nav iebūvētu laidiena pārvaldības rīku. Tā ir problēma, jo katram laidienam ir manuāli jāizveido lapa saplūšanā un jāmet tur visas laidienā iekļautās iespējas, jāmeklē pa prāta pilīm, uzdevumi jirā, commits repozitorijā. Ir daudz iespēju kļūdīties, varat kaut ko aizmirst vai ievadīt kaut ko, kas jau bija izlaists pagājušajā reizē, dažreiz vienkārši nav skaidrs, kā klasificēt vilkšanas pieprasījumu - vai tā ir funkcija vai kļūdu labojums, vai rediģēšanas testi, vai kaut kas infrastrukturāls.

Kā GitHub darbības var mums palīdzēt? Ir lieliska darbība — laidiena izstrādātājs, tas ļauj iestatīt izlaiduma piezīmju faila veidni, lai iestatītu izvilkšanas pieprasījumu kategorijas un automātiski grupētu tās izlaiduma piezīmju failā:

Veidnes piemērs pārskata iestatīšanai (.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

Pievienojiet skriptu, lai ģenerētu laidiena melnrakstu (.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 }}

Visi izvilkšanas pieprasījumi turpmāk tiks automātiski apkopoti izlaiduma piezīmēs - burvība!

Šeit var rasties jautājums: ko darīt, ja izstrādātāji aizmirst ievietot tagus PR? Tad nav skaidrs, kurā kategorijā to likt, un atkal ar to būs jātiek galā manuāli, ar katru PR atsevišķi. Lai novērstu šo problēmu, mēs varam izmantot citu darbību — etiķetes verificētāju — tas pārbauda, ​​vai vilkšanas pieprasījumā nav atzīmju. Ja nav nepieciešamo atzīmju, pārbaude būs neveiksmīga, un mēs redzēsim ziņojumu par to mūsu izvilkšanas pieprasījumā.

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'

Tagad jebkurš izvilkšanas pieprasījums ir jāatzīmē ar vienu no tagiem: type:fix, type:features, type:documentation, type:tests, type:config.

Izvilkšanas pieprasījumu automātiskā anotācija

Tā kā mēs pieskārāmies tādai tēmai kā efektīvs darbs ar izvilkšanas pieprasījumiem, ir vērts runāt par tādu darbību kā etiķetes, kas PR ievieto tagus, pamatojoties uz to, kādi faili ir mainīti. Piemēram, mēs varam atzīmēt kā [veidot] jebkuru vilkšanas pieprasījumu, kas satur izmaiņas direktorijā .github/workflow.

Savienošana ir pavisam vienkārša:

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

Mums ir nepieciešams arī fails, kurā aprakstīta atbilstība starp projekta direktorijiem un izvilkšanas pieprasījuma 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/**"

Man neizdevās savienot pārī darbību, kas automātiski ievieto iezīmes izvilkšanas pieprasījumos, ar darbību, kas pārbauda nepieciešamo iezīmju esamību; atbilstības etiķete nevēlas redzēt robota pievienotās iezīmes. Šķiet vieglāk uzrakstīt savu darbību, kas apvieno abus posmus. Bet pat šajā formā tas ir diezgan ērti lietojams, veidojot vilkšanas pieprasījumu, no saraksta ir jāizvēlas etiķete.

Ir pienācis laiks izvietot

Es izmēģināju vairākas izvietošanas iespējas, izmantojot GitHub Actions (izmantojot ssh, izmantojot scp un izmantojot docker-hub), un varu teikt, ka, visticamāk, jūs atradīsit veidu, kā augšupielādēt bināro failu serverī neatkarīgi no tā, cik greizs ir jūsu cauruļvads. ir.

Man patika iespēja visu infrastruktūru glabāt vienuviet, tāpēc apskatīsim, kā to izvietot GitHub pakotnēs (šī ir binārā satura, npm, jar, docker repozitorijs).

Skripts docker attēla izveidei un publicēšanai GitHub pakotnēs:

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

Pirmkārt, mums ir jāizveido mūsu lietojumprogrammas JAR fails, pēc kura mēs aprēķinām ceļu uz GitHub docker reģistru un mūsu attēla nosaukumu. Šeit ir daži triki, ar kuriem mēs vēl neesam saskārušies:

• tāda konstrukcija kā: echo “::set-output name=NAME::VALUE” ļauj iestatīt mainīgā vērtību pašreizējā darbībā, lai pēc tam to varētu nolasīt visās pārējās darbībās.
• varat iegūt iepriekšējā darbībā iestatītā mainīgā vērtību, izmantojot šīs darbības identifikatoru: ${{ steps.global_env.outputs.DOKERHUB_IMAGE_NAME }}
• Standarta mainīgais GITHUB_REPOSITORY saglabā repozitorija nosaukumu un tā īpašnieku (“īpašnieks/repo-nosaukums”). Lai izgrieztu visu no šīs rindas, izņemot repozitorija nosaukumu, mēs izmantosim bash sintaksi: ${GITHUB_REPOSITORY#*/}

Tālāk mums ir jāizveido doka attēls:

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

Piesakieties reģistrā:

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

Un publicējiet attēlu GitHub pakotņu krātuvē:

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

Lai norādītu attēla versiju, mēs izmantojam pirmos ciparus no commit SHA hash - GITHUB_SHA šeit ir arī nianses, ja jūs veicat šādas build ne tikai apvienojot galveno, bet arī pēc pull pieprasījuma izveides notikums, tad SHA var neatbilst jaukšanai, ko mēs redzam git vēsturē, jo darbības/izrakstīšanās darbība veido savu unikālo jaucēju, lai izvairītos no strupceļa darbībām PR.

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

Tur var redzēt arī docker attēla versiju sarakstu.

Atliek tikai konfigurēt mūsu serveri darbam ar šo reģistru un restartēt pakalpojumu. Par to, kā to izdarīt, izmantojot systemd, es droši vien runāšu citreiz.

Uzraudzība

Apskatīsim vienkāršu iespēju, kā veikt mūsu lietojumprogrammas veselības pārbaudi, izmantojot GitHub Actions. Mūsu sāknēšanas lietojumprogrammai ir izpildmehānisms, tāpēc mums pat nav jāraksta API, lai pārbaudītu tās statusu; mēs jau esam izdarījuši visu slinko labā. Jums vienkārši jāvelk saimniekdators: 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, lai pārbaudītu serveri, izmantojot cron, un, ja pēkšņi tas mums neatbild, mēs nosūtīsim paziņojumu ar telegrammas palīdzību.

Vispirms izdomāsim, kā palaist cron darbplūsmu:

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

Tas ir vienkārši, es pat nespēju noticēt, ka Github var izveidot notikumus, kas nemaz neiederas tīmekļa aizķerēs. Sīkāka informācija atrodama dokumentācijā: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Pārbaudīsim servera statusu manuāli, izmantojot 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"

Pirmkārt, mēs saglabājam mainīgajā, ko serveris atbildēja uz pieprasījumu, nākamajā darbībā pārbaudām, vai statuss ir UP, un, ja tas tā nav, izejam ar kļūdu. Ja jums ir nepieciešams "pārslogot" darbību ar rokām, tad izeja 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: |
        Health check of the:
        ${{secrets.SERVER_HOST}}/api/actuator/health
        failed with the result:
        ${{ steps.ping.outputs.status }}

Mēs nosūtām uz telegrammu tikai tad, ja darbība neizdevās iepriekšējā solī. Lai nosūtītu ziņojumu, mēs izmantojam appleboy/telegram-action; par to, kā iegūt bota marķieri un tērzēšanas ID, varat lasīt dokumentācijā: github.com/appleboy/telegram-action

Neaizmirstiet ierakstīt Github noslēpumus: URL serverim un marķierus telegrammas robotam.

Bonusa trase - JIRA slinkajiem

Es apsolīju, ka atgriezīsimies JIRA, un mēs esam atgriezušies. Simtiem reižu esmu novērojis situāciju stand-ups, kad izstrādātāji izveidoja līdzekli, apvienoja filiāli, bet aizmirsa ievilkt problēmu JIRA. Protams, ja tas viss tiktu izdarīts vienuviet, tas būtu vienkāršāk, bet patiesībā mēs rakstām kodu IDE, sapludinām zarus bitbucket vai GitHub un pēc tam ievelkam uzdevumus Jira, lai to izdarītu, mums ir jāatver jauni logi. , dažreiz piesakieties vēlreiz utt. Kad jūs lieliski atceraties, kas jums jādara tālāk, tad nav jēgas vēlreiz atvērt dēli. Tā rezultātā no rīta pie stāvēšanas jums jāpavada laiks, lai atjauninātu uzdevumu paneli.

GitHub mums palīdzēs arī šajā regulārajā uzdevumā; iesācējiem mēs varam automātiski ievilkt problēmas kolonnā code_review, kad iesniedzam izvilkšanas pieprasījumu. Viss, kas jums jādara, ir ievērot filiāļu nosaukšanas principu:

[имя проекта]-[номер таска]-название

piemēram, ja projekta atslēga "GitHub Actions" ir GA, tad GA-8-jira-bot varētu būt filiāle GA-8 uzdevuma īstenošanai.

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

Vispirms jums ir jāpiesakās 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 }}

Lai to izdarītu, jums jāiegūst JIRA marķieris, kā to izdarīt, ir aprakstīts šeit: confluence.atlassian.com/cloud/api-tokens-938839638.html

Mēs izņemam 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 "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}}

Ja meklējat GitHub tirgū, jūs varat atrast darbību šim uzdevumam, bet man bija jāraksta tas pats, izmantojot grep, izmantojot filiāles nosaukumu, jo šī darbība no Atlassian nekādā veidā nevēlējās strādāt pie mana projekta , lai saprastu, kas tur bija nepareizi - ilgāk, nekā to pašu darīt ar rokām.

Atliek tikai pārvietot uzdevumu uz kolonnu “Koda pārskatīšana”, veidojot izvilkšanas pieprasījumu:

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

Šim nolūkam pakalpojumā GitHub ir jāveic īpaša darbība. Viss, kas tam nepieciešams, ir iepriekšējā darbībā iegūtais problēmas ID un JIRA autorizācija, ko veicām iepriekš.

Tādā pašā veidā varat vilkt uzdevumus, apvienojot tos galvenajā versijā, un citus notikumus no GitHub darbplūsmas. Kopumā viss ir atkarīgs no jūsu iztēles un vēlmes automatizēt rutīnas procesus.

Atzinumi

Ja paskatās uz klasisko DEVOPS diagrammu, mēs esam aptvēruši visus posmus, izņemot varbūt darbību, es domāju, ka, ja jūs mēģināt, jūs varat atrast kādu darbību tirgū integrācijai ar palīdzības dienesta sistēmu, tāpēc mēs pieņemsim, ka cauruļvads pagriezās. jābūt rūpīgai, un, pamatojoties uz tā izmantošanu, var izdarīt secinājumus.

Plusi:

• Tirgus ar gatavām darbībām visiem gadījumiem, tas ir ļoti foršs. Lielākajā daļā no tiem varat arī apskatīt avota kodu, lai saprastu, kā atrisināt līdzīgu problēmu, vai publicēt funkcijas pieprasījumu autoram tieši GitHub repozitorijā.
• Mērķa platformas izvēle montāžai: Linux, mac os, Windows ir diezgan interesanta funkcija.
• Github Packages ir lieliska lieta, ir ērti turēt visu infrastruktūru vienuviet, jums nav sērfot pa dažādiem logiem, viss atrodas viena vai divu peles klikšķu rādiusā un ir lieliski integrēts ar GitHub Actions. Docker reģistra atbalsts bezmaksas versijā ir arī laba priekšrocība.
• GitHub slēpj noslēpumus veidošanas žurnālos, tāpēc tā izmantošana paroļu un marķieru glabāšanai nav tik biedējoša. Visu savu eksperimentu laikā es nekad nevarēju saskatīt noslēpumu tīrā veidā konsolē.
• Bezmaksas atvērtā pirmkoda projektiem

Mīnusi:

• YML, nu, man viņš nepatīk. Strādājot ar šādu plūsmu, visizplatītākais commit ziņojums man ir “fix yml format”, tad aizmirsti kaut kur ielikt cilni, vai arī ieraksti nepareizajā rindā. Kopumā sēdēšana pie ekrāna ar transportieri un lineālu nav tā patīkamākā pieredze.
• ATKLĀŠANA, plūsmas atkļūdošana ar commit, pārbūve un izvadīšana uz konsoli ne vienmēr ir ērta, taču tā vairāk pieder kategorijai “jūs esat pārspīlēts”; jūs esat pieradis strādāt ar ērtu IDEA, kad varat atkļūdot jebko. .
• Savu darbību var uzrakstīt uz jebko, ja iesaiņo to Docker, bet tikai javascript tiek natively atbalstīts, protams, tas ir gaumes jautājums, bet es gribētu kaut ko citu, nevis js.

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

Nākamnedēļ es uzstāšos ar Ziņot Heisenbug 2020 Piter konferencē. Es jums pastāstīšu ne tikai to, kā izvairīties no kļūdām, sagatavojot testa datus, bet arī dalīšos ar saviem noslēpumiem darbā ar datu kopām Java lietojumprogrammās!

Avots: www.habr.com