🥇Põrgu ringid koos GitHub Actionsiga (Java projekti jaoks CI/CD torujuhtme ehitamine)

Pean sageli Java-projektide ehitamiseks torujuhtme ehitama. Mõnikord on see avatud lähtekoodiga, mõnikord mitte. Otsustasin hiljuti proovida teisaldada mõned oma hoidlad Travis-CI-st ja TeamCityst GitHub Actionsi ja see tuli sellest välja.

Mida me automatiseerime?

Esiteks vajame projekti, mille automatiseerime, teeme väikese rakenduse Spring bootis / Java 11 / Mavenis. Selle artikli puhul ei huvita meid üldse rakendusloogika, meile on oluline rakendust ümbritsev infrastruktuur, seega piisab meile lihtsast REST API kontrollerist.

Allikaid saad vaadata siit: github.com/antkorwin/github-actions Kõik torujuhtme ehitamise etapid kajastuvad selle projekti tõmbamistaotlustes.

JIRA ja planeerimine

Tasub öelda, et tavaliselt kasutame JIRA-t probleemide jälgijana, seega loome selle projekti jaoks eraldi tahvli ja lisame sinna esimesed probleemid:

Natuke hiljem tuleme tagasi selle juurde, mida huvitavat JIRA ja GitHub koos pakuvad.

Automatiseerime projekti kokkupaneku

Meie testprojekt on ehitatud Maveni kaudu, nii et selle ehitamine on üsna lihtne, vajame vaid mvn puhast paketti.

Selleks, kasutades Githubi toiminguid, peame hoidlasse looma faili, mis kirjeldab meie töövoogu, seda saab teha tavalise yml-failiga, ma ei saa öelda, et mulle meeldib “yml programmeerimine”, aga mida me teha saame? teeme seda .github/ kataloogis töövoo/ faili build.yml, milles kirjeldame põhiharu loomise toiminguid:

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 — see on sündmuse kirjeldus, millel meie stsenaarium käivitatakse.

sisse: pull_request/push — näitab, et see töövoog tuleb käivitada iga kord, kui juhtseadmele tõuke tehakse ja tõmbetaotlused luuakse.

Järgmine on ülesannete kirjeldus (töökohti) ja täitmise sammud (samme) iga ülesande jaoks.

pealejooksmine - siin saame valida siht-OS-i, üllataval kombel saate valida isegi Mac OS-i, kuid privaatsetes hoidlates on see üsna kallis (võrreldes Linuxiga).

kasutusalad võimaldab teil uuesti kasutada muid toiminguid, näiteks installime Java 11 keskkonna installimise / setup-java toimingu abil.

Abil koos saame määrata parameetrid, millega toimingu käivitame; sisuliselt on need argumendid, mis toimingule edastatakse.

Jääb vaid käivitada projekti koos Maveniga: run: mvn -B clean package lipp -B ütleb, et meil on vaja mitteinteraktiivset režiimi, et mees äkki ei taha meilt midagi küsida

Suurepärane! Nüüd, iga kord, kui pühendute meistrile, algab projekti koostamine.

Testide käivitamise automatiseerimine

Kokkupanek on hea, kuid tegelikkuses saab projekti ohutult kokku panna, kuid mitte töötada. Seetõttu on järgmiseks sammuks testide automatiseerimine. Lisaks on PR-ülevaatust tehes üsna mugav vaadata testide läbimise tulemusi - teate kindlalt, et testid läbivad ja keegi ei unustanud enne ühendamist oma haru käivitada.

Tõmbepäringu loomisel teeme teste ja liidame masterisse ning samal ajal lisame koodi katvuse aruande loomise.

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

Testide katmiseks kasutan codecovi koos jacoco pistikprogrammiga. Codecovil on oma toiming, kuid see vajab meie tõmbamistaotlusega töötamiseks luba:

${{ secrets.CODECOV_TOKEN }} — seda konstruktsiooni näeme rohkem kui korra, saladused on GitHubis saladuste hoidmise mehhanism, sinna saame kirjutada paroole/tokeneid/hoste/url-e ja muid andmeid, mida hoidla koodibaasi lisada ei tohiks.

Saate lisada saladustele muutuja GitHubi hoidla seadetes:

Žetooni saate aadressilt codecov.io Pärast GitHubi kaudu autoriseerimist peate avaliku projekti lisamiseks järgima sellist linki: GitHubi kasutajanimi/[repo nimi]. Lisada saab ka privaatse hoidla, selleks pead andma Githubis olevale rakendusele codecovi õigused.

Lisage POM-faili jacoco pistikprogramm:

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

Nüüd sisestab codecov-bot iga meie tõmbamistaotluse ja lisab katvuse muutmise graafiku:

Lisame staatilise analüsaatori

Enamikus oma avatud lähtekoodiga projektides kasutan staatilise koodi analüüsimiseks sonaripilve, travis-ci-ga on üsna lihtne ühendust luua. Nii et GitHub Actionsile üleminekul on sama toimimiseks loogiline samm. Action market on lahe asi, aga seekord vedas mind veidi alt, sest harjumusest leidsin vajaliku tegevuse ja lisasin selle töövoogu. Kuid selgus, et sonar ei toeta Mavenil või Gradle'il projektide analüüsimise toimingu läbimist. Muidugi on see dokumentatsioonis kirjas, aga kes seda loeb?!

See ei ole toimingu kaudu võimalik, seega teeme seda mvn-plugina kaudu:

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 - saab aadressilt sonarcloud.io ja peate selle salajas registreerima. GITHUB_TOKEN - see on sisseehitatud žetoon, mille GitHub genereerib ja mille abil saab sonarcloud[bot] Giti sisse logida, et jätta meile tõmbetaotlustes sõnumeid.

Dsonar.projectKey — projekti nimi sonaris, näete seda projekti seadetes.

Dsonar.organisatsioon — organisatsiooni nimi GitHubist.

Teeme tõmbetaotluse ja ootame sonarcloud[bot] kommentaaridesse:

Väljalaske haldamine

Järel on konfigureeritud, testid on käivitatud ja saame väljalaske teha. Vaatame, kuidas GitHub Actions saab versioonide haldamise palju lihtsamaks muuta.

Tööl on mul projekte, mille koodibaas on bitbucketis (kõik on nagu selles loos “Päeval kirjutan bitbucketile, öösel pühendun GitHubile”). Kahjuks pole bitbucketil sisseehitatud väljalaskehaldustööriistu. See on probleem, sest iga väljalase jaoks tuleb käsitsi luua leht konfluentsis ja sinna visata kõik väljalases sisalduvad funktsioonid, otsida läbi meelepaleed, ülesanded jiras, commits repositooriumis. Võimalusi on palju eksida, võite midagi unustada või sisestada midagi, mis oli juba eelmisel korral välja antud, mõnikord pole lihtsalt selge, mille järgi tõmmata taotlust liigitada - kas see on funktsioon või veaparandus või redigeerimistestid või midagi infrastruktuurilist.

Kuidas saavad GitHubi toimingud meid aidata? Seal on suurepärane tegevus – väljalaske koostaja, see võimaldab teil määrata väljalaskemärkmete failimalli, et seadistada tõmbamistaotluste kategooriad ja rühmitada need automaatselt väljalaskemärkmete faili:

Näidismalli aruande seadistamiseks (.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

Lisage versiooni mustandi loomiseks skript (.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 }}

Kõik tõmbetaotlused kogutakse nüüdsest automaatselt väljalaskemärkmetesse – võlu!

Siin võib tekkida küsimus: mis siis, kui arendajad unustavad PR-sse sildid lisada? Siis pole selge, millisesse kategooriasse see panna, ja jällegi peate sellega käsitsi tegelema, iga PR-iga eraldi. Selle probleemi lahendamiseks saame kasutada teist toimingut – sildi kontrollijat –, mis kontrollib tõmbetaotlusel siltide olemasolu. Kui nõutavaid silte pole, siis kontroll nurjub ja me näeme oma tõmbamistaotluses sellekohast teadet.

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'

Nüüd tuleb kõik tõmbetaotlused märgistada ühe märgendiga: type:fix, type:features, type:documentation, type:tests, type:config.

Tõmbetaotluste automaatne märkimine

Kuna puudutasime sellist teemat nagu tõhus töö tõmbepäringutega, siis tasub rääkida sellisest toimingust nagu sildistaja, mis paneb PR-i sildid selle järgi, milliseid faile on muudetud. Näiteks võime märkida [ehitamiseks] mis tahes tõmbamistaotluse, mis sisaldab kataloogi muudatusi .github/workflow.

Selle ühendamine on üsna lihtne:

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

Vajame ka faili, mis kirjeldab projektikataloogide ja tõmbetaotluste teemade vahelist vastavust:

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

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

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

theme:documentation:
  - "docs/**"

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

Mul ei õnnestunud siduda toimingut, mis paigutab sildid tõmbepäringutesse automaatselt, toiminguga, mis kontrollib vajalike siltide olemasolu; vaste silt ei taha roboti lisatud silte näha. Tundub, et lihtsam on kirjutada oma tegevus, mis ühendab mõlemad etapid. Kuid isegi sellel kujul on seda üsna mugav kasutada, tõmbetaotluse loomisel peate loendist valima sildi.

On aeg kasutusele võtta

Proovisin GitHub Actionsi kaudu mitut juurutusvalikut (ssh, scp ja docker-hubi kaudu) ja võin öelda, et suure tõenäosusega leiate viisi binaarfaili serverisse üleslaadimiseks, olenemata sellest, kui kõver on teie torujuhe on.

Mulle meeldis võimalus hoida kogu infrastruktuur ühes kohas, nii et vaatame, kuidas GitHubi pakettides juurutada (see on binaarse sisu, npm, jar, dockeri hoidla).

Dockeri kujutise loomiseks ja GitHubi pakettides avaldamiseks mõeldud skript:

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

Esiteks peame ehitama oma rakenduse JAR-faili, mille järel arvutame GitHubi dokkimisregistri tee ja oma pildi nime. Siin on mõned nipid, mida me pole veel kohanud:

konstruktsioon nagu: echo “::set-output name=NAME::VALUE” võimaldab määrata muutuja väärtuse praeguses etapis, nii et seda saab lugeda kõigis teistes etappides.
eelmises etapis määratud muutuja väärtuse saate selle sammu identifikaatori kaudu: ${{ steps.global_env.outputs.DOKERHUB_IMAGE_NAME }}
Standardne muutuja GITHUB_REPOSITORY salvestab hoidla nime ja selle omaniku (“omanik/repo-nimi”). Selleks, et lõigata sellelt realt kõik peale hoidla nime, kasutame bashi süntaksit: ${GITHUB_REPOSITORY#*/}

Järgmisena peame ehitama dokkeri kujutise:

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

Logige registrisse sisse:

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

Ja avaldage pilt GitHubi pakettide hoidlas:

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

Pildi versiooni näitamiseks kasutame commit'i SHA räsi esimesi numbreid - GITHUB_SHA on siin ka nüansse, kui teha selliseid builde mitte ainult master'iks liitmisel, vaid ka vastavalt tõmbepäringu loomisele sündmus, siis ei pruugi SHA ühtida räsiga, mida näeme giti ajaloos, sest toimingud/väljavõtutoiming teeb oma ainulaadse räsi, et vältida PR-s ummikseisu toiminguid.

Kui kõik õnnestus hästi, siis avades hoidlas pakettide jaotise (https://github.com/antkorwin/github-actions/packages), näete uut dokkeri pilti:

Seal näete ka dokipildi versioonide loendit.

Jääb üle vaid konfigureerida meie server selle registriga töötama ja teenus taaskäivitada. Tõenäoliselt räägin sellest, kuidas seda systemd kaudu teha, mõni teine kord.

Jälgimine

Vaatame lihtsat võimalust, kuidas GitHub Actionsi abil oma rakenduse tervisekontrolli teha. Meie alglaadimisrakendusel on täiturmehhanism, nii et me ei pea selle oleku kontrollimiseks isegi API-d kirjutama; oleme laiskade jaoks kõik juba ära teinud. Peate lihtsalt hosti tõmbama: 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"}

Kõik, mida vajame, on kirjutada cron-i abil serveri kontrollimiseks ülesanne ja kui see äkki ei vasta, saadame telegrammi teel teate.

Esiteks mõelgem välja, kuidas käivitada cron töövoogu:

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

See on lihtne, ma ei suuda isegi uskuda, et Githubis saate luua sündmusi, mis veebihaagidesse üldse ei sobi. Üksikasjad on dokumentatsioonis: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Kontrollime serveri olekut käsitsi curli abil:

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"

Esmalt salvestame muutujasse selle, mida server päringule vastas, järgmises etapis kontrollime, et olek on UP ja kui see nii ei ole, siis väljume veaga. Kui teil on vaja toimingut kätega üle koormata, siis väljumine 1 - sobiv relv.

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

Saadame telegrammi ainult siis, kui toiming eelmises etapis ebaõnnestus. Sõnumi saatmiseks kasutame appleboy/telegram-actionit; boti märgi ja vestluse ID hankimise kohta saate lugeda dokumentatsioonist: github.com/appleboy/telegram-action

Ärge unustage Githubi saladusi kirjutada: serveri URL ja telegrammi roboti märgid.

Boonuspala – JIRA laiskadele

Lubasin, et tuleme JIRAsse tagasi ja oleme tagasi. Olen sadu kordi jälginud stand-up'idel olukorda, kus arendajad lõid funktsiooni, ühendasid haru, kuid unustasid probleemi JIRAsse lohistada. Muidugi, kui seda kõike ühes kohas teha, oleks see lihtsam, kuid tegelikult kirjutame IDE-s koodi, ühendame harud bitbucketisse või GitHubisse ja lohistame ülesanded Jirasse, selleks peame avama uued aknad , vahel logi uuesti sisse jne. Kui mäletate suurepäraselt, mida peate järgmiseks tegema, pole mõtet tahvlit uuesti avada. Selle tulemusena peate hommikul püstijalu veetma aega tegumitahvli värskendamiseks.

GitHub aitab meid ka selles rutiinses ülesandes. Alustuseks saame tõmbamistaotluse esitamisel probleemid automaatselt veergu code_review lohistada. Kõik, mida pead tegema, on järgida haru nimetamise tava:

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

Näiteks kui projektivõti "GitHub Actions" on GA, siis GA-8-jira-bot võiks olla haru GA-8 ülesande rakendamiseks.

Integratsioon JIRA-ga toimib Atlassiani toimingute kaudu, need pole täiuslikud, pean ütlema, et mõned neist ei töötanud minu jaoks üldse. Kuid käsitleme ainult neid, mis kindlasti töötavad ja mida aktiivselt kasutatakse.

Esmalt tuleb JIRAsse sisse logida, kasutades toimingut: 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 }}

Selleks tuleb hankida JIRA-s token, kuidas seda teha on kirjeldatud siin: confluence.atlassian.com/cloud/api-tokens-938839638.html

Ekstraktime ülesande identifikaatori haru nimest:

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

Kui otsite GitHubi turuplatsil, leiate selle ülesande jaoks toimingu, kuid ma pidin sama asja kirjutama grep-i kasutades haru nime, kuna see Atlassiani toiming ei tahtnud minu projektiga kuidagi töötada , et aru saada, mis seal valesti oli – kauem kui sama kätega teha.

Jääb üle vaid tõmbepäringu loomisel ülesanne teisaldada veergu „Koodi ülevaatus”.

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

GitHubis on selleks spetsiaalne toiming. Kõik, mida see vajab, on eelmises etapis saadud probleemi ID ja JIRA autoriseerimine, mida me ülal tegime.

Samamoodi saate lohistada ülesandeid, kui ühendate põhifaili, ja muid sündmusi GitHubi töövoost. Üldiselt sõltub kõik teie kujutlusvõimest ja soovist rutiinseid protsesse automatiseerida.

Järeldused

Kui vaatate klassikalist DEVOPS-i diagrammi, oleme hõlmanud kõiki etappe, välja arvatud võib-olla tegutsemine, ma arvan, et kui proovite, leiate turult mõne toimingu kasutajatoe süsteemiga integreerimiseks, seega eeldame, et torujuhe pöördus põhjalik ja selle kasutamise põhjal saab teha järeldusi.

plussid:

Turg koos valmistoimingutega igaks juhuks, see on väga lahe. Enamiku neist saate vaadata ka lähtekoodi, et mõista, kuidas sarnast probleemi lahendada, või postitada funktsioonipäringu autorile otse GitHubi hoidlasse.
Sihtplatvormi valimine kokkupanekuks: Linux, mac os, Windows on üsna huvitav funktsioon.
Githubi paketid on suurepärane asi, kogu taristut on mugav hoida ühes kohas, ei pea surfama erinevates akendes, kõik on ühe-kahe hiireklõpsu raadiuses ja on GitHub Actionsiga ideaalselt integreeritud. Dockeri registri tugi tasuta versioonis on samuti hea eelis.
GitHub peidab ehituslogidesse saladusi, nii et selle kasutamine paroolide ja žetoonide salvestamiseks pole nii hirmutav. Kõigi oma katsete ajal ei näinud ma kunagi konsoolis saladust puhtal kujul.
Tasuta avatud lähtekoodiga projektide jaoks

miinuseid:

YML, noh, ta ei meeldi mulle. Sellise vooga töötades on mul kõige levinum commit sõnum “fix yml format”, siis unustad kuhugi vahelehe panna või kirjutad selle valele reale. Üldiselt pole nurganurga ja joonlauaga ekraani ees istumine just kõige meeldivam kogemus.
SILUMINE, voo silumine sissekannetega, ümberehituse käivitamine ja konsooli väljastamine ei ole alati mugav, kuid see on pigem "olete üle pingutatud" kategooria; olete harjunud töötama mugava IDEA-ga, kui saate siluda mida tahes .
Dockerisse mähkimisel saate oma tegevuse kirjutada ükskõik mille peale, kuid ainult javascript on natiivselt toetatud, see on muidugi maitse asi, kuid js-i asemel eelistaksin midagi muud.

Lubage mul teile meelde tuletada, et hoidla koos kõigi skriptidega on siin: github.com/antkorwin/github-actions

Järgmisel nädalal esinen koos aruanne Heisenbug 2020 Piteri konverentsil. Ma ei räägi teile mitte ainult sellest, kuidas vältida vigu testiandmete ettevalmistamisel, vaid jagan ka oma Java-rakenduste andmekogumitega töötamise saladusi!

Allikas: www.habr.com

Põrgu ringid koos GitHubi toimingutega (Java projekti jaoks CI/CD torujuhtme ehitamine)