Circles of Hell GitHub Actions-ekin (Java proiektu baterako CI/CD kanalizazioa eraikitzea)

Askotan Java-n proiektuak eraikitzeko kanalizazio bat eraiki behar izaten dut. Batzuetan kode irekia da, beste batzuetan ez. Duela gutxi nire biltegietako batzuk Travis-CI eta TeamCity-tik GitHub Actions-era eramaten saiatzea erabaki nuen, eta hau da hortik atera zena.

Zer automatizatuko dugu?

Lehenik eta behin, automatizatuko dugun proiektu bat behar dugu, egin dezagun Spring boot / Java 11 / Maven aplikazio txiki bat. Artikulu honen ondorioetarako, ez zaigu batere interesatuko aplikazioaren logika; aplikazioaren inguruko azpiegitura garrantzitsua da guretzat, beraz, REST API kontrolatzaile soil bat nahikoa izango da.

Hemen ikus ditzakezu iturriak: github.com/antkorwin/github-actions Kanalizazio bat eraikitzeko fase guztiak proiektu honen tira-eskaeretan islatzen dira.

JIRA eta plangintza

Esan beharra dago JIRA normalean arazoen jarraitzaile gisa erabiltzen dugula, beraz, sor ditzagun proiektu honetarako taula berezi bat eta gehi ditzagun lehen gaiak bertan:

Pixka bat geroago JIRAk eta GitHub-ek konbinatuta eskain ditzaketen gauza interesgarrietara itzuliko gara.

Proiektuaren muntaia automatizatzen dugu

Gure proba-proiektua maven bidez eraikitzen da, beraz, eraikitzea nahiko erraza da, behar dugun guztia mvn clean paketea da.

Github Actions erabiliz, gure lan-fluxua deskribatzen duen biltegian fitxategi bat sortu beharko dugu, hau yml fitxategi arrunt batekin egin daiteke, ezin dut esan "yml programazioa" gustatzen zaidanik, baina zer egin dezakegu - .github/ direktorioa workflow/ build.yml fitxategian egiten dugu eta bertan adar maisua eraikitzerakoan ekintzak deskribatuko ditugu:

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 — hau gure gidoia abiaraziko den ekitaldiaren deskribapena da.

on: pull_request/push — adierazten du lan-fluxu hori abiarazi behar dela maisuari push bat egiten zaion bakoitzean eta tira eskaerak sortzen diren bakoitzean.

Jarraian zereginen deskribapena da (lanpostu) eta exekuzio urratsak (urrats) zeregin bakoitzerako.

korrika egiten - Hemen helburuko OS hauta dezakegu, harrigarria bada ere, Mac OS ere aukeratu dezakezu, baina biltegi pribatuetan hau nahiko garestia da (Linuxekin alderatuta).

erabilerak Beste ekintza batzuk berrerabiltzeko aukera ematen dizu, adibidez, Java 11-rako ingurunea instalatzen dugun ekintzak/setup-java ekintza erabiliz.

Bidez batera ekintza abiarazten dugun parametroak zehaztu ditzakegu, funtsean hauek dira ekintzara pasatuko diren argumentuak.

Geratzen dena da Maven-ekin proiektua eraikitzea: run: mvn -B clean package bandera -B dio modu ez-interaktibo bat behar dugula, adituak bat-batean ezer galdetu nahi ez diezagun

Bikaina! Orain, maisuarekin konpromisoa hartzen duzun bakoitzean, proiektuaren eraikuntza hasten da.

Proba abiarazteak automatizatzea

Muntaketa ona da, baina errealitatean, proiektu bat segurtasunez munta daiteke, baina ez funtzionatzen. Beraz, hurrengo urratsa probak automatizatzea da. Horrez gain, nahiko komenigarria da PR berrikuspena egiten duzunean probak gainditzearen emaitzak ikustea - ziur badakizu probak gainditzen dituela eta inork ez du ahaztu bere adarra exekutatzen bateratzea egin aurretik.

Tira-eskaera bat sortzean probak egingo ditugu eta maisuan batu, eta, aldi berean, kode-estaldurari buruzko txosten baten sorrera gehituko dugu.

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

Probak estaltzeko, codecov erabiltzen dut jacoco pluginarekin batera. codecov-ek bere ekintza propioa du, baina token bat behar du gure tira eskaerarekin lan egiteko:

${{ secrets.CODECOV_TOKEN }} — eraikuntza hau behin baino gehiagotan ikusiko dugu, sekretuak GitHub-en sekretuak gordetzeko mekanismo bat da, bertan idatzi ditzakegu pasahitzak/tokenak/hosts/url-ak eta biltegiko kode oinarrian sartu behar ez diren beste datu batzuk.

Aldagai bat gehi diezaiekezu sekretuei GitHub-eko biltegiaren ezarpenetan:

Token bat lor dezakezu codecov.io GitHub-en bidez baimendu ondoren, proiektu publiko bat gehitzeko honelako esteka bat jarraitu behar duzu: GitHub erabiltzaile-izena/[repo izena]. Biltegi pribatu bat ere gehi daiteke; horretarako, Github-eko aplikazioari codecov eskubideak eman behar dizkiozu.

Gehitu jacoco plugina POM fitxategira:

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

Orain codecov bot-ak gure tira-eskaera bakoitza sartuko du eta estaldura-aldaketa grafiko bat gehituko du:

Gehitu dezagun analizatzaile estatiko bat

Nire kode irekiko proiektu gehienetan kode estatikoko analisirako sonar hodeia erabiltzen dut, nahiko erraza da travis-ci-ra konektatzea. Beraz, urrats logikoa da GitHub Actions-era migratzean gauza bera egitea. Ekintza-merkatua gauza polita da, baina oraingoan apur bat utzi nau, ohituragatik behar nuen ekintza aurkitu eta lan-fluxura gehitu nuelako. Baina ondorioztatu zen sonarrak ez duela onartzen maven edo gradle-n proiektuak aztertzeko ekintza baten bidez lan egitea. Hori noski, dokumentazioan idatzita dago, baina nork irakurtzen du?!

Ez da posible ekintza baten bidez, beraz, mvn pluginaren bidez egingo dugu:

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 - helbidean lor daiteke sonarcloud.io eta sekretuan erregistratu behar duzu. GITHUB_TOKEN - GitHub-ek sortzen duen token integratua da, eta horren laguntzaz sonarcloud[bot]-ek Git-en saioa hasi ahal izango du, tira-eskaeretan mezuak uzteko.

Dsonar.projectKey — proiektuaren izena sonarean, proiektuaren ezarpenetan ikus dezakezu.

Dsonar.antolaketa — GitHub-eko erakundearen izena.

Pull-eskaera bat egiten dugu eta iruzkinetan sonarcloud[bot] noiz etorriko itxarongo dugu:

Argitalpenen kudeaketa

Eraikina konfiguratu da, probak exekutatu dira eta kaleratze bat egin dezakegu. Ikus dezagun GitHub Actions-ek askapenen kudeaketa askoz errazagoa izan dezakeen.

Lanean, kode-oinarria bitbucket-en duten proiektuak ditut (dena istorio horretan bezala da "bitbucket-i egunean idazten dut, gauez GitHub-era konprometitu"). Zoritxarrez, bitbucket-ek ez du oharra kudeatzeko tresna integratuta. Hau arazo bat da, zeren bertsio bakoitzeko orri bat eskuz sortu behar duzulako konfluentzian eta kaleratzean sartutako ezaugarri guztiak bertan bota, gogoaren jauregietan bilatu, jira-n zereginak, biltegian konprometituak. Akatsen bat egiteko aukera asko daude, zerbait ahaztu dezakezu edo azken aldian kaleratu zen zerbait sar dezakezu, batzuetan ez dago argi tira-eskaera bat nola sailkatu behar den - funtzio bat ala akatsen konponketa, edo edizio-probak ala, edo zerbait azpiegiturazkoa.

Nola lagun diezagukete GitHub-en ekintzek? Ekintza bikaina dago: kaleratze-egilea, kaleratze-oharrak fitxategi-txantiloi bat ezartzeko aukera ematen du tira-eskaeren kategoriak konfiguratzeko eta automatikoki kaleratze-oharraren fitxategian taldekatzeko:

Txosten bat konfiguratzeko txantiloi adibidea (.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

Gehitu script bat argitalpen zirriborro bat sortzeko (.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 }}

Hemendik aurrera ateratze-eskaera guztiak bertsio-oharretan bilduko dira automatikoki - magia!

Hemen galdera sor daiteke: zer gertatzen da garatzaileek PR-an etiketak jartzea ahazten badute? Orduan ez dago argi zein kategoriatan jarri, eta berriro eskuz landu beharko duzu, PR bakoitza bereizita. Arazo hau konpontzeko, beste ekintza bat erabil dezakegu - etiketa egiaztatzailea - tira eskaeran etiketak dauden egiaztatzen du. Beharrezko etiketarik ez badago, egiaztapenak huts egingo du eta honi buruzko mezu bat ikusiko dugu gure tira eskaeran.

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'

Orain edozein tira-eskaera etiketa batekin markatu behar da: type:fix, type: Features, type:documentation, type:tests, type:config.

Tiro-eskaeren oharpen automatikoa

Tira-eskaerekin lan eraginkorra bezalako gai bat ukitu genuenez, merezi du etiketatzaile gisako ekintza bati buruz hitz egitea, PR-an etiketak jartzen ditu aldatu diren fitxategien arabera. Adibidez, [eraiki] gisa markatu dezakegu direktorioan aldaketak dituen edozein tira eskaera .github/workflow.

Konexioa nahiko erraza da:

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

Proiektuaren direktorioen eta pull request gaien arteko korrespondentzia deskribatzen duen fitxategi bat ere behar dugu:

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

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

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

theme:documentation:
  - "docs/**"

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

Ez nuen lortu tira-eskaeretan etiketak automatikoki jartzen dituen ekintza eta beharrezko etiketen presentzia egiaztatzen duen ekintza parekatzea; match-label-ek ez du bot-ak gehitutako etiketak ikusi nahi. Errazagoa dirudi bi etapak uztartzen dituen zure ekintza idaztea. Baina inprimaki honetan ere nahiko erosoa da erabiltzea; zerrendatik etiketa bat hautatu behar duzu tira eskaera bat sortzean.

Zabaltzeko garaia da

Hainbat inplementazio-aukera probatu nituen GitHub Actions-en bidez (ssh bidez, scp bidez eta docker-hub erabiliz), eta esan dezaket, ziurrenik, bitarra zerbitzarira igotzeko modu bat aurkituko duzula, zure kanalizazioa zein okerra izan arren. da.

Azpiegitura osoa leku bakarrean mantentzeko aukera gustatu zitzaidan, beraz, ikus dezagun GitHub paketeetan nola zabaldu (hau eduki bitarren biltegia da, npm, jar, docker).

Docker irudi bat eraikitzeko eta GitHub paketeetan argitaratzeko scripta:

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

Lehenik eta behin, gure aplikazioaren JAR fitxategia eraiki behar dugu, ondoren GitHub docker erregistrorako bidea eta gure irudiaren izena kalkulatuko ditugu. Hemen daude oraindik aurkitu ez ditugun trikimailu batzuk:

• bezalako eraikuntza batek: echo “::set-output name=NAME::VALUE” aldagai baten balioa uneko urratsean ezartzeko aukera ematen du, beste urrats guztietan irakurri ahal izateko.
• aurreko urratsean ezarritako aldagaiaren balioa urrats honen identifikatzailearen bidez lor dezakezu: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• GITHUB_REPOSITORY aldagai estandarrak biltegiaren izena eta bere jabea gordetzen ditu ("jabea/repo-izena"). Lerro honetatik dena mozteko biltegiaren izena izan ezik, bash sintaxia erabiliko dugu: ${GITHUB_REPOSITORY#*/}

Ondoren, docker irudia eraiki behar dugu:

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

Hasi saioa erregistroan:

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

Eta argitaratu irudia GitHub Packages Repository-en:

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

Irudiaren bertsioa adierazteko, konpromezuaren SHA hash-eko lehen zenbakiak erabiltzen ditugu - GITHUB_SHA ñabardurak ere badaude hemen, horrelako eraikuntzak egiten badituzu ez bakarrik maisuarekin bateratzean, baita tira eskaeraren sorreraren arabera ere. gertaera, orduan SHA baliteke git historian ikusten dugun hash-arekin bat ez datorrela, ekintzak/checkout ekintzak bere hash berezia egiten duelako PR-en blokeo ekintzak saihesteko.

Dena ondo atera bada, paketeen atala irekiz (https://github.com/antkorwin/github-actions/packages) biltegian, docker irudi berri bat ikusiko duzu:

Bertan docker irudiaren bertsioen zerrenda ere ikus dezakezu.

Gure zerbitzaria erregistro honekin lan egiteko eta zerbitzua berrabiaraztea besterik ez da geratzen. Seguruenik, sistemaren bidez nola egin behar den hitz egingo dut beste behin.

jarraipenaren

Ikus dezagun GitHub Actions erabiliz gure aplikazioaren osasun egiaztapena nola egin jakiteko aukera erraz bat. Gure abiarazte-aplikazioak eragingailu bat du, beraz, ez dugu APIrik idatzi behar ere bere egoera egiaztatzeko; dagoeneko egin dugu dena alferrarentzat. Ostalaria atera besterik ez duzu behar: 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"}

Zerbitzaria cron erabiliz egiaztatzeko ataza bat idaztea besterik ez dugu behar, eta bat-batean ez badigu erantzuten, jakinarazpen bat bidaliko dugu telegramean.

Lehenik eta behin, ikus dezagun nola exekutatu cron lan-fluxua:

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

Sinplea da, ezin dut sinetsi ere Github-en webhooketan batere sartzen ez diren gertaerak sor ditzakezuenik. Xehetasunak dokumentazioan daude: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Egiaztatu dezagun zerbitzariaren egoera eskuz curl bidez:

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"

Lehenik eta behin, aldagai batean gordetzen dugu zerbitzariak eskaerari erantzun diona, hurrengo urratsean egoera GORA dagoela egiaztatuko dugu eta, horrela ez bada, akats batekin irteten gara. Ekintza bat eskuekin "gainditu" behar baduzu, orduan 1. irteera - arma egokia.

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

Telegramara bidaltzen dugu ekintzak aurreko urratsean huts egin badu. Mezu bat bidaltzeko appleboy/telegram-action erabiltzen dugu; dokumentazioan bot token bat eta txataren IDa nola lortu irakur dezakezu: github.com/appleboy/telegram-action

Ez ahaztu Github-en sekretuak idaztea: zerbitzariaren URLa eta telegram bot-aren tokenak.

Bonus track - JIRA alferrarentzat

JIRAra itzuliko ginela agindu nion, eta bueltatu gara. Ehunka aldiz ikusi dut egoera bat stand-upetan garatzaileek eginbide bat egin zutenean, adar bat batu zutenean, baina arazoa JIRAra arrastatzea ahaztu zitzaidan. Jakina, hori guztia leku bakarrean egingo balitz, errazagoa izango litzateke, baina egia esan kodea idazten dugu IDEan, adarrak bitbucket edo GitHub-en bateratzen ditugu eta gero arrastatu zereginak Jira-ra, horretarako leiho berriak ireki behar ditugu. , batzuetan berriro saioa hasi eta abar. Ondoren egin behar duzuna ondo gogoratzen duzunean, orduan ez du balio taula berriro irekitzea. Ondorioz, goizean standup batean denbora eman behar duzu zereginen taula eguneratzen.

GitHub-ek ohiko zeregin honetan ere lagunduko digu; hasteko, automatikoki arrastatu ditzakegu arazoak code_review zutabera tira eskaera bat bidaltzen dugunean. Egin behar duzun guztia adar izendatzeko konbentzioa jarraitzea da:

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

adibidez, "GitHub Actions" proiektuaren gakoa GA bada, orduan GA-8-jira-bot GA-8 zeregina ezartzeko adar bat izan liteke.

JIRArekin integrazioak Atlassian-eko ekintzen bidez funtzionatzen du, ez dira perfektuak, esan behar dut horietako batzuk ez zaizkidala batere balio. Baina behin betiko funtzionatzen dutenak eta aktiboki erabiltzen direnak bakarrik eztabaidatuko ditugu.

Lehenik eta behin JIRAn saioa hasi behar duzu ekintza hau erabiliz: 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 }}

Horretarako, token bat lortu behar duzu JIRAn, hau nola egin deskribatzen da hemen: confluence.atlassian.com/cloud/api-tokens-938839638.html

Adarraren izenetik zereginaren identifikatzailea ateratzen dugu:

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

GitHub merkatuan bilatzen baduzu, zeregin honetarako ekintza bat aurki dezakezu, baina grep erabiliz gauza bera idatzi behar izan nuen adarraren izena erabiliz, Atlassian-en ekintza honek ez zuelako nire proiektuan inola ere landu nahi. , han zer zegoen gaizki jakiteko - eskuekin gauza bera egitea baino luzeagoa.

Geratzen dena da zeregina "Kodea berrikustea" zutabera eramatea tira eskaera bat sortzean:

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

GitHub-en ekintza berezi bat dago horretarako, aurreko urratsean lortutako gaiaren IDa eta goian egin dugun JIRA-n baimena besterik ez du behar.

Modu berean, atazak arrastatu ditzakezu maisuan bat egiten duzunean, eta GitHub lan-fluxuko beste gertaera batzuk. Oro har, dena zure irudimenaren eta ohiko prozesuak automatizatzeko gogoaren araberakoa da.

Findings

DEVOPS diagrama klasikoari erreparatzen badiogu, fase guztiak estali ditugu, agian funtzionatzea izan ezik. Saiatzen bazara, laguntza-mahai sistemarekin integratzeko merkatuan ekintza batzuk aurki ditzakezula uste dut, beraz, kanalizazioa piztu dela suposatuko dugu. sakona izatea eta erabileraren arabera ondorioak atera daitezke.

Pros:

• Okasio guztietarako prest dauden ekintzak dituen merkatua, oso polita da. Gehienetan, iturburu-kodea ere begiratu dezakezu antzeko arazo bat nola konpondu ulertzeko edo eginbide-eskaera bat egileari zuzenean GitHub biltegian argitaratzeko.
• Muntatzeko xede-plataforma hautatzea: Linux, mac os, windows nahiko ezaugarri interesgarria da.
• Github Packages gauza bikaina da, komenigarria da azpiegitura osoa leku bakarrean edukitzea, ez duzu leiho ezberdinetatik nabigatu beharrik, dena saguaren klik bat edo biren erradioan dago eta ezin hobeto integratuta dago GitHub Actions-ekin. Docker erregistroaren laguntza doako bertsioan ere abantaila ona da.
• GitHub-ek sekretuak ezkutatzen ditu eraikuntza-erregistroetan, beraz, pasahitzak eta tokenak gordetzeko erabiltzea ez da horren beldurgarria. Nire esperimentu guztietan, inoiz ez nuen sekretua bere forma hutsean ikusi kontsolan.
• Kode irekiko proiektuetarako doan

Cons:

• YML, tira, ez zait gustatzen. Horrelako fluxu batekin lan egiten dudanean, nik daukadan konpromezu-mezurik ohikoena "konpondu yml formatua" da, orduan ahaztu egiten zaizu fitxa bat nonbait jartzea, edo okerreko lerroan idazten duzu. Oro har, protractor eta erregela duen pantaila baten aurrean esertzea ez da esperientziarik atseginena.
• DEBUG, fluxua konpromezuekin araztea, berreraikitze bat exekutatu eta kontsolara ateratzea ez da beti komenigarria, baina "gehiegi zaude" kategoriakoa da; IDEA erosoarekin lan egitera ohituta zaude, edozer arazketa dezakezunean. .
• Zure ekintza edozertan idatz dezakezu Docker-en biltzen baduzu, baina javascript bakarrik onartzen da natiboki, noski hau gustu kontua da, baina js-en ordez beste zerbait nahiago nuke.

Gogorarazten dizut script guztiak dituen biltegia hemen dagoela: github.com/antkorwin/github-actions

Datorren astean batera arituko naiz txostena Heisenbug 2020 Piter konferentzian. Proba datuak prestatzerakoan akatsak nola saihestu ez ezik, Java aplikazioetako datu-multzoekin lan egiteko nire sekretuak ere partekatuko dizut!

Iturria: www.habr.com