Cercuri ale iadului cu GitHub Actions (construirea unei conducte CI/CD pentru un proiect Java)

De multe ori trebuie să construiesc o conductă pentru proiecte de construcție în Java. Uneori este open source, alteori nu. Recent am decis să încerc să mut unele dintre depozitele mele de la Travis-CI și TeamCity în GitHub Actions, iar asta a rezultat.

Ce vom automatiza?

Mai întâi, avem nevoie de un proiect pe care îl vom automatiza, să facem o mică aplicație în Spring boot / Java 11 / Maven. În sensul acestui articol, nu ne va interesa deloc logica aplicației; infrastructura din jurul aplicației este importantă pentru noi, așa că un simplu controler REST API ne va fi suficient.

Puteti vizualiza sursele aici: github.com/antkorwin/github-actions Toate etapele construirii unei conducte sunt reflectate în cererile de tragere pentru acest proiect.

JIRA și planificare

Merită să spunem că de obicei folosim JIRA ca un instrument de urmărire a problemelor, așa că haideți să creăm o tablă separată pentru acest proiect și să adăugăm primele probleme acolo:

Puțin mai târziu vom reveni la ce lucruri interesante pot oferi JIRA și GitHub în combinație.

Automatizăm asamblarea proiectului

Proiectul nostru de testare este construit prin maven, așa că construirea este destul de simplă, tot ce avem nevoie este pachetul mvn clean.

Pentru a face acest lucru folosind Github Actions, va trebui să creăm un fișier în depozit care descrie fluxul nostru de lucru, acest lucru se poate face cu un fișier yml obișnuit, nu pot spune că îmi place „programarea yml”, dar ce putem face - o facem în directorul .github/ workflow/ fișier build.yml în care vom descrie acțiunile la construirea ramurii master:

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 — aceasta este o descriere a evenimentului la care va fi lansat scenariul nostru.

pe: pull_request/push — indică faptul că acest flux de lucru trebuie să fie lansat de fiecare dată când se face un push către master și se creează cereri de extragere.

Mai jos este o descriere a sarcinilor (de locuri de muncă) și pașii de execuție (paşi) pentru fiecare sarcină.

rulează pe - aici putem selecta sistemul de operare țintă, în mod surprinzător, puteți alege chiar și Mac OS, dar pe depozitele private acest lucru este destul de scump (comparativ cu Linux).

utilizări vă permite să reutilizați alte acțiuni, de exemplu, folosind acțiunea acțiuni/setup-java, instalăm mediul pentru Java 11.

Cu ajutorul cu putem specifica parametrii cu care lansăm acțiunea; în esență, acestea sunt argumentele care vor fi transmise acțiunii.

Tot ce rămâne este să rulezi proiectul în Maven: run: mvn -B clean package pavilion -B spune că avem nevoie de un mod non-interactiv, astfel încât expertul să nu vrea brusc să ne întrebe ceva

Grozav! Acum, de fiecare dată când te angajezi în fața maestrului, începe construcția proiectului.

Automatizarea lansărilor de teste

Asamblarea este bună, dar, în realitate, un proiect poate fi asamblat în siguranță, dar nu funcționează. Prin urmare, următorul pas este automatizarea testelor. În plus, este destul de convenabil să te uiți la rezultatele trecerii testelor atunci când faci o revizuire PR - știi sigur că testele trec și nimeni nu a uitat să-și conducă filiala înainte de a face o fuziune.

Vom rula teste atunci când creăm o cerere de extragere și vom îmbina în master și, în același timp, vom adăuga crearea unui raport privind acoperirea codului.

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

Pentru a acoperi teste, folosesc codecov împreună cu pluginul jacoco. codecov are propria sa acțiune, dar are nevoie de un token pentru a funcționa cu cererea noastră de extragere:

${{ secrets.CODECOV_TOKEN }} — vom vedea această construcție de mai multe ori, secrets este un mecanism de stocare a secretelor în GitHub, putem scrie acolo parole/token-uri/hosts/url-uri și alte date care nu ar trebui incluse în baza de cod al depozitului.

Puteți adăuga o variabilă la secrete în setările depozitului de pe GitHub:

Puteți obține un jeton la codecov.io După autorizarea prin GitHub, pentru a adăuga un proiect public, trebuie doar să urmați un link ca acesta: Nume de utilizator GitHub/[nume repo]. De asemenea, poate fi adăugat un depozit privat; pentru a face acest lucru, trebuie să acordați drepturi codecov aplicației în Github.

Adăugați pluginul jacoco în fișierul 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>

Acum, botul codecov va introduce fiecare dintre solicitările noastre de extragere și va adăuga un grafic de modificare a acoperirii:

Să adăugăm un analizor static

În majoritatea proiectelor mele open source, folosesc sonar cloud pentru analiza statică a codului, este destul de ușor să mă conectez la travis-ci. Deci, este un pas logic atunci când migrați la GitHub Actions să faceți același lucru. Piața de acțiuni este un lucru mișto, dar de data aceasta m-a dezamăgit puțin, pentru că din obișnuință am găsit acțiunea de care aveam nevoie și am adăugat-o în fluxul de lucru. Dar s-a dovedit că sonarul nu acceptă lucrul printr-o acțiune pentru analiza proiectelor pe maven sau gradle. Desigur, asta este scris în documentație, dar cine o citește?!

Nu este posibil printr-o acțiune, așa că o vom face prin plugin-ul 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 - se poate obține la sonarcloud.io și trebuie să-l înregistrați în secret. GITHUB_TOKEN - acesta este un token încorporat pe care îl generează GitHub, cu ajutorul căruia sonarcloud[bot] se va putea conecta la Git pentru a ne lăsa mesaje în cererile de extragere.

Dsonar.projectKey — numele proiectului în sonar, îl puteți vedea în setările proiectului.

Dsonar.organizare — numele organizației din GitHub.

Facem o cerere de extragere și așteptăm ca sonarcloud[bot] să vină în comentarii:

Gestiunea gestiunii

Construcția a fost configurată, testele au fost rulate și putem face o lansare. Să ne uităm la modul în care GitHub Actions poate face gestionarea versiunilor mult mai ușoară.

La serviciu, am proiecte a căror bază de cod este în bitbucket (totul este ca în povestea aceea „Scriu pe bitbucket ziua, commit la GitHub noaptea”). Din păcate, bitbucket nu are instrumente de gestionare a versiunilor încorporate. Aceasta este o problemă, deoarece pentru fiecare lansare trebuie să creați manual o pagină în confluență și să aruncați acolo toate caracteristicile incluse în ediție, să căutați prin palatele minții, sarcini în jira, comite în depozit. Există multe șanse de a face o greșeală, puteți uita ceva sau puteți introduce ceva care a fost deja lansat data trecută, uneori pur și simplu nu este clar cum să clasificați o solicitare de extragere - este o caracteristică sau o remediere a erorilor, sau teste de editare sau ceva infrastructural.

Cum ne pot ajuta acțiunile GitHub? Există o acțiune grozavă - redactorul de lansare, vă permite să setați un șablon de fișier cu note de lansare pentru a configura categorii de solicitări de extragere și să le grupați automat în fișierul cu note de lansare:

Exemplu de șablon pentru configurarea unui raport (.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

Adăugați un script pentru a genera o versiune nefinalizată (.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 }}

Toate solicitările de extragere de acum încolo vor fi colectate automat în notele de lansare - magic!

Aici poate apărea întrebarea: ce se întâmplă dacă dezvoltatorii uită să pună etichete în PR? Atunci nu este clar în ce categorie să-l încadrezi și din nou va trebui să te ocupi de ea manual, cu fiecare PR separat. Pentru a remedia această problemă, putem folosi o altă acțiune - verificatorul de etichete - verifică prezența etichetelor în cererea de extragere. Dacă nu există etichete necesare, atunci verificarea va fi eșuată și vom vedea un mesaj despre acest lucru în cererea noastră de extragere.

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'

Acum orice solicitare de extragere trebuie să fie marcată cu una dintre etichetele: type:fix, type:features, type:documentation, type:tests, type:config.

Adnotarea automată a solicitărilor de extragere

Deoarece am atins un subiect precum munca eficientă cu solicitări de extragere, merită să vorbim despre o astfel de acțiune precum etichetatorul, acesta pune etichete în PR în funcție de fișierele care au fost modificate. De exemplu, putem marca ca [build] orice cerere de extragere care conține modificări ale directorului .github/workflow.

Conectarea este destul de simplă:

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

De asemenea, avem nevoie de un fișier care să descrie corespondența dintre directoarele proiectului și subiectele cererii de extragere:

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

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

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

theme:documentation:
  - "docs/**"

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

Nu am reușit să asociez acțiunea care plasează automat etichete în cererile de extragere cu acțiunea care verifică prezența etichetelor necesare; match-label nu vrea să vadă etichetele adăugate de bot. Pare mai ușor să-ți scrii propria acțiune care combină ambele etape. Dar chiar și în această formă este destul de convenabil de utilizat; trebuie să selectați o etichetă din listă atunci când creați o cerere de extragere.

Este timpul să desfășurăm

Am încercat mai multe opțiuni de implementare prin GitHub Actions (prin ssh, prin scp și folosind docker-hub) și pot spune că, cel mai probabil, veți găsi o modalitate de a încărca binarul pe server, indiferent cât de strâmbă este pipeline-ul dvs. este.

Mi-a plăcut opțiunea de a păstra întreaga infrastructură într-un singur loc, așa că să ne uităm la modul de implementare în pachetele GitHub (acesta este un depozit pentru conținut binar, npm, jar, docker).

Script pentru construirea unei imagini Docker și publicarea acesteia în pachetele 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 }}"

Mai întâi, trebuie să construim fișierul JAR al aplicației noastre, după care calculăm calea către registrul docker GitHub și numele imaginii noastre. Există câteva trucuri aici pe care nu le-am întâlnit încă:

• o construcție precum: echo „::set-output name=NAME::VALUE” vă permite să setați valoarea unei variabile în pasul curent, astfel încât să poată fi apoi citită în toți ceilalți pași.
• puteți obține valoarea variabilei setate în pasul anterior prin identificatorul acestui pas: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• Variabila standard GITHUB_REPOSITORY stochează numele depozitului și proprietarul acestuia („proprietar/nume-repo”). Pentru a tăia totul din această linie, cu excepția numelui depozitului, vom folosi sintaxa bash: ${GITHUB_REPOSITORY#*/}

În continuare trebuie să construim imaginea docker:

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

Conectați-vă la registru:

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

Și publicați imaginea în depozitul de pachete GitHub:

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

Pentru a indica versiunea imaginii, folosim primele cifre din hash-ul SHA al commit-ului - GITHUB_SHA există și nuanțe aici, dacă faceți astfel de versiuni nu numai atunci când vă îmbinați în master, ci și în funcție de crearea cererii de extragere. eveniment, atunci SHA poate să nu se potrivească cu hash-ul pe care îl vedem în istoricul git, deoarece acțiunea de acțiuni/checkout își face propriul hash unic pentru a evita acțiunile de blocare în PR.

Dacă totul a funcționat bine, atunci deschizând secțiunea de pachete (https://github.com/antkorwin/github-actions/packages) în depozit, veți vedea o nouă imagine docker:

Acolo puteți vedea și o listă de versiuni ale imaginii docker.

Tot ce rămâne este să configurați serverul nostru să funcționeze cu acest registru și să reporniți serviciul. Probabil voi vorbi despre cum să fac asta prin systemd altă dată.

monitorizarea

Să ne uităm la o opțiune simplă despre cum să faceți o verificare a stării de sănătate a aplicației noastre folosind GitHub Actions. Aplicația noastră de pornire are un actuator, așa că nici măcar nu trebuie să scriem un API pentru a-i verifica starea; am făcut deja totul pentru leneși. Trebuie doar să trageți gazda: 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"}

Tot ce avem nevoie este să scriem o sarcină pentru a verifica serverul folosind cron, iar dacă brusc nu ne răspunde, atunci vom trimite o notificare prin telegramă.

Mai întâi, să ne dăm seama cum să rulăm un flux de lucru cron:

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

Este simplu, nici nu-mi vine să cred că în Github poți crea evenimente care nu se potrivesc deloc în webhook-uri. Detalii sunt in documentatie: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Să verificăm manual starea serverului prin 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"

Mai întâi, salvăm într-o variabilă ce a răspuns serverul la cerere, în pasul următor verificăm dacă starea este UP și, dacă nu este cazul, ieșim cu o eroare. Dacă trebuie să „copășești” o acțiune cu mâinile, atunci iesirea 1 - arma potrivita.

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

Trimitem la telegramă doar dacă acțiunea a eșuat la pasul anterior. Pentru a trimite un mesaj folosim appleboy/telegram-action; puteți citi despre cum să obțineți un token bot și un ID de chat în documentație: github.com/appleboy/telegram-action

Nu uitați să scrieți în secretele de pe Github: URL pentru server și token-uri pentru botul telegram.

Bonus track - JIRA pentru leneși

Am promis că ne vom întoarce la JIRA și ne-am întors. De sute de ori am observat o situație la stand-up când dezvoltatorii au creat o caracteristică, au fuzionat o ramură, dar au uitat să trag problema în JIRA. Desigur, dacă toate acestea ar fi făcute într-un singur loc, ar fi mai ușor, dar de fapt scriem cod în IDE, îmbinăm ramuri în bitbucket sau GitHub și apoi tragem sarcinile în Jira, pentru aceasta trebuie să deschidem ferestre noi. , uneori conectați-vă din nou și etc. Când vă amintiți perfect ce trebuie să faceți în continuare, atunci nu are rost să deschideți din nou tabla. În consecință, dimineața, la standup, trebuie să petreceți timp pentru a actualiza panoul de activități.

De asemenea, GitHub ne va ajuta în această sarcină de rutină; pentru început, putem trage automat problemele în coloana code_review atunci când trimitem o cerere de extragere. Tot ce trebuie să faceți este să urmați convenția de denumire a ramurilor:

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

de exemplu, dacă cheia de proiect „GitHub Actions” este GA, atunci GA-8-jira-bot ar putea fi o ramură pentru implementarea sarcinii GA-8.

Integrarea cu JIRA funcționează prin acțiuni din Atlassian, nu sunt perfecte, trebuie să spun că unele dintre ele nu au funcționat deloc la mine. Dar vom discuta doar despre cele care funcționează cu siguranță și sunt utilizate în mod activ.

Mai întâi trebuie să vă conectați la JIRA utilizând acțiunea: 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 }}

Pentru a face acest lucru, trebuie să obțineți un token în JIRA, cum să faceți acest lucru este descris aici: confluence.atlassian.com/cloud/api-tokens-938839638.html

Extragem identificatorul sarcinii din numele sucursalei:

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

Dacă căutați în piața GitHub, puteți găsi o acțiune pentru această sarcină, dar a trebuit să scriu același lucru folosind grep folosind numele ramurii, deoarece această acțiune de la Atlassian nu a vrut să lucreze la proiectul meu în niciun fel , pentru a-ți da seama ce a fost în neregulă acolo - mai mult decât să faci același lucru cu mâinile tale.

Tot ce rămâne este să mutați sarcina în coloana „Revizuire cod” atunci când creați o cerere de extragere:

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

Există o acțiune specială pentru aceasta pe GitHub, tot ce are nevoie este ID-ul problemei obținut la pasul anterior și autorizarea în JIRA pe care am făcut-o mai sus.

În același mod, puteți trage sarcini atunci când vă îmbinați în master și alte evenimente din fluxul de lucru GitHub. În general, totul depinde de imaginația și dorința ta de a automatiza procesele de rutină.

Constatări

Dacă te uiți la diagrama clasică DEVOPS, am acoperit toate etapele, cu excepția poate opera, cred că dacă încerci, poți găsi ceva acțiuni pe piață pentru integrarea cu sistemul de help-desk, așa că vom presupune că conducta sa întors. să fie minuțios și se pot trage concluzii pe baza utilizării sale.

Pro-uri:

• Piață cu acțiuni gata făcute pentru toate ocaziile, aceasta este foarte tare. În cele mai multe dintre ele, puteți, de asemenea, să vă uitați la codul sursă pentru a înțelege cum să rezolvați o problemă similară sau să postați o solicitare de caracteristică către autor direct în depozitul GitHub.
• Selectarea platformei țintă pentru asamblare: Linux, mac os, windows este o caracteristică destul de interesantă.
• Github Packages este un lucru grozav, este convenabil să păstrați întreaga infrastructură într-un singur loc, nu trebuie să navigați prin ferestre diferite, totul se află pe o rază de unul sau două clicuri de mouse și este perfect integrat cu GitHub Actions. Suportul pentru registry Docker în versiunea gratuită este, de asemenea, un avantaj bun.
• GitHub ascunde secrete în jurnalele de construcție, așa că folosirea lui pentru a stoca parole și jetoane nu este atât de înfricoșătoare. În timpul tuturor experimentelor mele, nu am reușit niciodată să văd secretul în forma sa pură în consolă.
• Gratuit pentru proiecte Open Source

Contra:

• YML, ei bine, nu-mi place de el. Când lucrez cu un astfel de flux, cel mai frecvent mesaj de commit pe care îl am este „fix yml format”, apoi uiți să pui o filă undeva sau o scrii pe o linie greșită. În general, a sta în fața unui ecran cu raportor și riglă nu este cea mai plăcută experiență.
• DEBUG, depanarea fluxului cu comiteri, rularea unei reconstruiri și ieșirea către consolă nu este întotdeauna convenabilă, dar este mai mult din categoria „ai exagerat”; ești obișnuit să lucrezi cu IDEA convenabilă, când poți depana orice .
• Puteți scrie acțiunea dvs. pe orice dacă o includeți în Docker, dar numai javascript este acceptat nativ, desigur că aceasta este o chestiune de gust, dar aș prefera altceva în loc de js.

Permiteți-mi să vă reamintesc că depozitul cu toate scripturile este aici: github.com/antkorwin/github-actions

Săptămâna viitoare voi cânta cu raport la conferința Heisenbug 2020 Piter. Vă voi spune nu numai cum să evitați greșelile atunci când pregătiți datele de testare, dar și să vă împărtășesc secretele mele de a lucra cu seturi de date în aplicațiile Java!

Sursa: www.habr.com