🥇Circles of the hell with GitHub Actions (budovanie CI/CD pipeline pre projekt Java)

Často musím stavať potrubie na budovanie projektov v Jave. Niekedy je to open source, niekedy nie. Nedávno som sa rozhodol, že skúsim presunúť niektoré z mojich úložísk z Travis-CI a TeamCity do GitHub Actions a vzišlo z toho toto.

Čo budeme automatizovať?

Najprv potrebujeme projekt, ktorý budeme automatizovať, urobme si malú aplikáciu v Spring boot / Java 11 / Maven. Aplikačná logika nás pre účely tohto článku vôbec nebude zaujímať, dôležitá je pre nás infraštruktúra okolo aplikácie, takže nám postačí jednoduchý REST API ovládač.

Zdroje si môžete pozrieť tu: github.com/antkorwin/github-actions Všetky fázy budovania potrubia sa odrážajú v požiadavkách na stiahnutie pre tento projekt.

JIRA a plánovanie

Stojí za to povedať, že zvyčajne používame JIRA ako nástroj na sledovanie problémov, takže vytvorte samostatnú nástenku pre tento projekt a pridajte tam prvé problémy:

O niečo neskôr sa vrátime k tomu, čo zaujímavé môžu JIRA a GitHub ponúknuť v kombinácii.

Automatizujeme montáž projektu

Náš testovací projekt je zostavený cez maven, takže jeho zostavenie je celkom jednoduché, všetko, čo potrebujeme, je balík mvn clean.

Aby sme to urobili pomocou Github Actions, budeme musieť v úložisku vytvoriť súbor popisujúci náš pracovný postup, to sa dá urobiť pomocou bežného yml súboru, nemôžem povedať, že by som mal rád „yml programovanie“, ale čo môžeme robiť - robíme to v adresári .github/ workflow/ súbor build.yml, v ktorom popíšeme akcie pri zostavovaní hlavnej vetvy:

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 — toto je popis udalosti, pri ktorej sa spustí náš skript.

na: pull_request/push — označuje, že tento pracovný postup je potrebné spustiť vždy, keď sa vykoná push na hlavný server a vytvoria sa požiadavky na stiahnutie.

Nasleduje popis úloh (pracovných miest) a kroky vykonávania (kroky) pre každú úlohu.

nábehov - tu môžeme vybrať cieľový OS, prekvapivo si môžete vybrať aj Mac OS, ale na súkromných úložiskách je to dosť drahé (v porovnaní s Linuxom).

používa umožňuje znova použiť iné akcie, napríklad pomocou akcie/nastavenia-java nainštalujeme prostredie pre Java 11.

Prostredníctvom s môžeme špecifikovať parametre, s ktorými spustíme akciu, v podstate sú to argumenty, ktoré budú odovzdané akcii.

Zostáva len spustiť zostavenie projektu v Maven: run: mvn -B clean package vlajka -B hovorí, že potrebujeme neinteraktívny režim, aby sa nás majster zrazu nechcel na niečo pýtať

Skvelé! Teraz, zakaždým, keď sa zaviažete k hlavnej úlohe, začne sa zostavovanie projektu.

Automatické spustenie testu

Montáž je dobrá, ale v skutočnosti sa dá projekt bezpečne zmontovať, ale nefunguje. Ďalším krokom je preto automatizácia testovacích chodov. Okrem toho je celkom vhodné pozrieť sa na výsledky absolvovania testov, keď robíte PR recenziu - určite viete, že testy prejdú a nikto nezabudol spustiť svoju pobočku pred vykonaním zlúčenia.

Spustíme testy pri vytváraní pull requestu a zlúčenie do mastera a zároveň pridáme vytvorenie reportu o pokrytí kódu.

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

Na pokrytie testov používam codecov v spojení s pluginom jacoco. codecov má svoju vlastnú akciu, ale na prácu s našou požiadavkou na stiahnutie potrebuje token:

${{ secrets.CODECOV_TOKEN }} — túto konštrukciu uvidíme viackrát, secrets je mechanizmus na ukladanie tajomstiev v GitHub, môžeme tam písať heslá/tokeny/hosts/url a ďalšie údaje, ktoré by nemali byť zahrnuté v kódovej báze úložiska.

Premennú môžete pridať do tajomstiev v nastaveniach úložiska na GitHub:

Token môžete získať na codecov.io Po autorizácii cez GitHub, ak chcete pridať verejný projekt, stačí nasledovať odkaz, ako je tento: Používateľské meno GitHub/[názov repo]. Je možné pridať aj súkromné úložisko; na tento účel musíte aplikácii udeliť práva codecov v Github.

Pridajte doplnok jacoco do súboru POM:

<plugin>
	<groupId>org.jacoco</groupId>
	<artifactId>jacoco-maven-plugin</artifactId>
	<version>0.8.4</version>
	<executions>
		<execution>
			<goals>
				<goal>prepare-agent</goal>
			</goals>
		</execution>
		<!-- attached to Maven test phase -->
		<execution>
			<id>report</id>
			<phase>test</phase>
			<goals>
				<goal>report</goal>
			</goals>
		</execution>
	</executions>
</plugin>
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<version>2.22.2</version>
	<configuration>
		<reportFormat>plain</reportFormat>
		<includes>
			<include>**/*Test*.java</include>
			<include>**/*IT*.java</include>
		</includes>
	</configuration>
</plugin>

Teraz robot codecov zadá každú z našich požiadaviek na stiahnutie a pridá graf zmeny pokrytia:

Pridajme statický analyzátor

Vo väčšine mojich open source projektov používam sonar cloud na statickú analýzu kódu, je celkom jednoduché pripojiť sa k travis-ci. Je to teda logický krok pri migrácii na akcie GitHub urobiť to isté. Akčný trh je fajn vec, no tentoraz ma trochu sklamal, pretože som zo zvyku našiel akciu, ktorú som potreboval a pridal som ju do pracovného postupu. Ukázalo sa však, že sonar nepodporuje prácu prostredníctvom akcie na analýzu projektov na maven alebo gradle. Samozrejme je to napísané v dokumentácii, ale kto to číta?!

Nie je to možné prostredníctvom akcie, takže to urobíme pomocou doplnku 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 - možno získať na sonarcloud.io a treba to zapísať do tajničiek. GITHUB_TOKEN - toto je vstavaný token, ktorý GitHub generuje, pomocou ktorého sa sonarcloud[bot] bude môcť prihlásiť do Git, aby nám nechal správy v žiadostiach o stiahnutie.

Dsonar.projectKey — názov projektu v sonare, môžete ho vidieť v nastaveniach projektu.

Dsonar.organizácia — názov organizácie z GitHubu.

Požiadame o stiahnutie a čakáme, kým sonarcloud [bot] príde do komentárov:

správa release

Zostava bola nakonfigurovaná, testy boli spustené a môžeme vydať vydanie. Pozrime sa, ako môžu akcie GitHub výrazne zjednodušiť správu vydaní.

V práci mám projekty, ktorých kódová základňa je v bitbuckete (všetko je ako v tom príbehu „cez deň píšem na bitbucket, v noci sa zaväzujem na GitHub“). Bohužiaľ, bitbucket nemá vstavané nástroje na správu vydania. To je problém, pretože pre každé vydanie musíte manuálne vytvoriť stránku v confluence a nahodiť tam všetky funkcie obsiahnuté vo vydaní, prehľadávať paláce mysle, úlohy v jira, commity v úložisku. Existuje veľa šancí, že sa pomýlite, môžete niečo zabudnúť alebo zadať niečo, čo už bolo vydané minule, niekedy jednoducho nie je jasné, ako zaradiť požiadavku na stiahnutie – ide o funkciu alebo opravu chyby, prípadne testy úprav, alebo niečo infraštrukturálne.

Ako nám môžu pomôcť akcie GitHubu? Je tu skvelá akcia – návrhár vydania, ktorý vám umožňuje nastaviť šablónu súboru poznámok k vydaniu na nastavenie kategórií žiadostí o stiahnutie a automaticky ich zoskupiť v súbore poznámok k vydaniu:

Príklad šablóny na nastavenie prehľadu (.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

Pridajte skript na vygenerovanie konceptu vydania (.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 }}

Všetky žiadosti o stiahnutie sa odteraz budú automaticky zhromažďovať v poznámkach k vydaniu – mágia!

Tu môže vzniknúť otázka: čo ak vývojári zabudnú vložiť značky do PR? Potom nie je jasné, do ktorej kategórie to zaradiť a opäť to budete musieť riešiť manuálne, s každým PR zvlášť. Na vyriešenie tohto problému môžeme použiť inú akciu – verifikátor štítkov – kontroluje prítomnosť značiek v požiadavke na stiahnutie. Ak neexistujú žiadne požadované značky, kontrola zlyhá a v našej žiadosti o stiahnutie sa zobrazí správa o tom.

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'

Teraz musí byť každá požiadavka na stiahnutie označená jednou zo značiek: type:fix, type:features, type:documentation, type:tests, type:config.

Automatická anotácia požiadaviek na stiahnutie

Keďže sme sa dotkli takej témy, ako je efektívna práca s požiadavkami na stiahnutie, stojí za to hovoriť o takej akcii, ako je labeler, ktorý vkladá značky do PR, na základe ktorých boli zmenené súbory. Napríklad môžeme označiť ako [build] akúkoľvek požiadavku na stiahnutie, ktorá obsahuje zmeny v adresári .github/workflow.

Zapojenie je celkom jednoduché:

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

Potrebujeme tiež súbor popisujúci súlad medzi adresármi projektu a témami žiadosti o stiahnutie:

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

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

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

theme:documentation:
  - "docs/**"

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

Nepodarilo sa mi spárovať akciu, ktorá automaticky umiestňuje štítky do žiadostí o stiahnutie, s akciou, ktorá kontroluje prítomnosť požadovaných štítkov; match-label nechce vidieť štítky pridané robotom. Zdá sa jednoduchšie napísať vlastnú akciu, ktorá kombinuje obe fázy. Ale aj v tejto forme je použitie celkom pohodlné, pri vytváraní požiadavky na stiahnutie je potrebné vybrať štítok zo zoznamu.

Je čas nasadiť

Vyskúšal som niekoľko možností nasadenia cez GitHub Actions (cez ssh, cez scp a pomocou docker-hub) a môžem povedať, že s najväčšou pravdepodobnosťou nájdete spôsob, ako nahrať binárny súbor na server, bez ohľadu na to, ako pokrivený je váš kanál je.

Páčila sa mi možnosť ponechať celú infraštruktúru na jednom mieste, takže sa pozrime na to, ako nasadiť do balíkov GitHub (toto je úložisko pre binárny obsah, npm, jar, docker).

Skript na vytvorenie obrazu docker a jeho publikovanie v balíkoch GitHub:

name: Deploy docker image

on:
  push:
    branches:
      - 'master'

jobs:

  build_docker_image:
    runs-on: ubuntu-18.04
    steps:

#     Build JAR:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean compile package -DskipTests

#     Set global environment variables:
      - name: set global env
        id: global_env
        run: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"

#     Build Docker image:
      - name: Build and tag image
        run: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - name: Docker login
        run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publish image to github package repository:
      - name: Publish image
        env:
          IMAGE_NAME: $GITHUB_REPOSITORY
        run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"

Najprv musíme vytvoriť súbor JAR našej aplikácie, potom vypočítame cestu k registru GitHub docker a názov nášho obrázka. Existuje niekoľko trikov, s ktorými sme sa ešte nestretli:

konštrukcia ako: echo “::set-output name=NAME::VALUE” vám umožňuje nastaviť hodnotu premennej v aktuálnom kroku, aby sa potom dala prečítať vo všetkých ostatných krokoch.
hodnotu premennej nastavenej v predchádzajúcom kroku môžete získať prostredníctvom identifikátora tohto kroku: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
Štandardná premenná GITHUB_REPOSITORY ukladá názov úložiska a jeho vlastníka („owner/repo-name“). Aby sme z tohto riadku vyňali všetko okrem názvu úložiska, použijeme bash syntax: ${GITHUB_REPOSITORY#*/}

Ďalej musíme vytvoriť obrázok docker:

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

Prihláste sa do registra:

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

A publikujte obrázok do úložiska balíkov GitHub:

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

Na označenie verzie obrázka používame prvé číslice z hashu SHA odovzdania - GITHUB_SHA sú tu aj nuansy, ak takéto zostavy robíte nielen pri spájaní do mastera, ale aj podľa vytvárania požiadavky na stiahnutie udalosť, potom sa SHA nemusí zhodovať s hashom, ktorý vidíme v histórii git, pretože akcia akcie/pokladňa vytvára svoj vlastný jedinečný hash, aby sa zabránilo uviaznutiu akcií v PR.

Ak všetko fungovalo dobre, po otvorení sekcie balíkov (https://github.com/antkorwin/github-actions/packages) v úložisku uvidíte nový obrázok docker:

Tam môžete vidieť aj zoznam verzií obrázka docker.

Zostáva iba nakonfigurovať náš server na prácu s týmto registrom a reštartovať službu. O tom, ako to urobiť prostredníctvom systemd, budem pravdepodobne hovoriť inokedy.

monitorovanie

Pozrime sa na jednoduchú možnosť, ako vykonať kontrolu stavu našej aplikácie pomocou akcií GitHub. Naša bootovacia aplikácia má aktuátor, takže na kontrolu jej stavu ani nepotrebujeme písať API; už sme urobili všetko pre lenivých. Stačí stiahnuť hostiteľa: 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"}

Všetko, čo potrebujeme, je napísať úlohu na kontrolu servera pomocou cronu, a ak nám zrazu neodpovie, pošleme vám upozornenie v telegrame.

Po prvé, poďme zistiť, ako spustiť pracovný postup cronu:

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

Je to jednoduché, ani sa mi nechce veriť, že v Github môžete vytvárať udalosti, ktoré sa vôbec nehodia do webhookov. Podrobnosti sú v dokumentácii: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Poďme skontrolovať stav servera manuálne pomocou 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"

Najprv do premennej uložíme, čo server odpovedal na požiadavku, v ďalšom kroku skontrolujeme, či je stav UP a ak tomu tak nie je, skončíme s chybou. Ak potrebujete „premôcť“ akciu rukami, potom výstup 1 - vhodná zbraň.

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

Do telegramu posielame iba vtedy, ak akcia zlyhala v predchádzajúcom kroku. Na odoslanie správy používame appleboy/telegram-action; o tom, ako získať token bota a ID chatu, si môžete prečítať v dokumentácii: github.com/appleboy/telegram-action

Nezabudnite napísať do tajov na Github: URL pre server a tokeny pre telegramového robota.

Bonusová skladba - JIRA pre lenivých

Sľúbil som, že sa vrátime do JIRA a vrátili sme sa. Stovkykrát som pozoroval situáciu na stand-upoch, keď vývojári vytvorili funkciu, zlúčili vetvu, ale zabudli pretiahnuť problém do JIRA. Samozrejme, ak by sa to všetko urobilo na jednom mieste, bolo by to jednoduchšie, ale v skutočnosti napíšeme kód do IDE, zlúčime vetvy do bitbucket alebo GitHub a potom pretiahneme úlohy do Jira, na to musíme otvoriť nové okná , niekedy sa znova prihláste atď. Keď si dokonale zapamätáte, čo musíte urobiť ďalej, potom nemá zmysel znovu otvárať dosku. Výsledkom je, že ráno pri standupe musíte tráviť čas aktualizáciou tabule úloh.

GitHub nám tiež pomôže v tejto rutinnej úlohe; pre začiatočníkov môžeme problémy automaticky presunúť do stĺpca code_review, keď odošleme požiadavku na stiahnutie. Všetko, čo musíte urobiť, je dodržiavať konvenciu pomenovania pobočiek:

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

ak je napríklad kľúč projektu „GitHub Actions“ GA, potom GA-8-jira-bot by mohla byť vetvou na implementáciu úlohy GA-8.

Integrácia s JIRA funguje cez akcie od Atlassianu, nie sú dokonalé, musím povedať, že niektoré mi vôbec nefungovali. Ale budeme diskutovať len o tých, ktoré určite fungujú a sú aktívne využívané.

Najprv sa musíte prihlásiť do JIRA pomocou akcie: 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 }}

Ak to chcete urobiť, musíte získať token v JIRA, ako to urobiť, je popísané tu: confluence.atlassian.com/cloud/api-tokens-938839638.html

Z názvu pobočky extrahujeme identifikátor úlohy:

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

Ak hľadáte na trhovisku GitHub, môžete nájsť akciu pre túto úlohu, ale to isté som musel napísať pomocou grep pomocou názvu pobočky, pretože táto akcia od Atlassianu nechcela nijako pracovať na mojom projekte , prísť na to, čo tam bolo zle – dlhšie ako robiť to isté rukami.

Zostáva len presunúť úlohu do stĺpca „Preskúmanie kódu“ pri vytváraní požiadavky na stiahnutie:

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

Na GitHub existuje špeciálna akcia, všetko, čo potrebuje, je ID problému získané v predchádzajúcom kroku a autorizácia v JIRA, ktorú sme urobili vyššie.

Rovnakým spôsobom môžete presúvať úlohy pri zlučovaní do hlavnej a ďalšie udalosti z pracovného toku GitHub. Vo všeobecnosti to všetko závisí od vašej fantázie a túžby automatizovať rutinné procesy.

Závery

Ak sa pozriete na klasický DEVOPS diagram, pokryli sme všetky fázy, snáď s výnimkou prevádzky, myslím, že ak sa pokúsite, nájdete na trhu nejakú akciu pre integráciu so systémom help-desk, takže budeme predpokladať, že sa potrubie otočilo byť dôkladný a na základe jeho použitia možno vyvodiť závery.

Pros:

Trhovisko s pripravenými akciami pre všetky príležitosti, to je veľmi cool. Vo väčšine z nich si môžete pozrieť aj zdrojový kód, aby ste pochopili, ako vyriešiť podobný problém, alebo odoslať požiadavku na funkciu autorovi priamo v úložisku GitHub.
Výber cieľovej platformy pre zostavenie: Linux, mac os, windows je celkom zaujímavá funkcia.
Balíky Github sú skvelá vec, je pohodlné mať celú infraštruktúru na jednom mieste, nemusíte surfovať cez rôzne okná, všetko je v okruhu jedného alebo dvoch kliknutí myšou a je dokonale integrované s akciami GitHub. Dobrou výhodou je aj podpora registrov Docker v bezplatnej verzii.
GitHub skrýva tajomstvá v protokoloch zostavovania, takže jeho použitie na ukladanie hesiel a tokenov nie je také strašidelné. Počas všetkých mojich experimentov som nikdy nemohol vidieť tajomstvo v jeho čistej forme v konzole.
Zadarmo pre projekty s otvoreným zdrojom

Nevýhody:

YML, no, nemám ho rád. Pri práci s takýmto tokom je najbežnejšia správa o odovzdaní „fix yml format“, potom zabudnete niekam vložiť kartu alebo ju napíšete na nesprávny riadok. Vo všeobecnosti platí, že sedieť pred obrazovkou s uhlomerom a pravítkom nie je práve najpríjemnejší zážitok.
DEBUG, ladenie toku pomocou commitov, spustenie prestavby a výstup na konzolu nie je vždy pohodlné, ale je to skôr kategória „prehnali ste to“; ste zvyknutí pracovať s pohodlným IDEA, keď môžete ladiť čokoľvek .
Svoju akciu môžete napísať na čokoľvek, ak to zabalíte do Dockera, ale natívne je podporovaný iba javascript, to je samozrejme vec vkusu, ale namiesto js by som preferoval niečo iné.

Dovoľte mi pripomenúť, že úložisko so všetkými skriptami je tu: github.com/antkorwin/github-actions

Budúci týždeň budem vystupovať s správa na konferencii Heisenbug 2020 Piter. Poviem vám nielen to, ako sa vyhnúť chybám pri príprave testovacích údajov, ale podelím sa aj o svoje tajomstvá práce so súbormi údajov v aplikáciách Java!

Zdroj: hab.com

Kruhy pekla s akciami GitHub (vybudovanie kanála CI/CD pre projekt Java)