Gyakran kell CI/CD folyamatot építenem Java projektekhez. Néha ez nyílt forráskódú, néha nem. Nemrégiben úgy döntöttem, hogy kipróbálom, hogyan tudnám átkonvertálni néhány repómat Travis-CI-ről és TeamCity-ről GitHub Actions-ra, és ez lett belőle.
Mit fogunk automatizálni
Először is szükségünk van egy projektre, amit automatizálni fogunk, csináljunk egy egyszerű alkalmazást Spring Boot / Java 11 / Maven. A cikk keretein belül az alkalmazás logikája nem érdekel bennünket, nekünk az alkalmazás körüli infrastruktúra a lényeg, így elegendő egy egyszerű REST API vezérlő.
A forráskódot itt találhatjuk: a pipeline építési lépései benne találhatók a projekt pull-requests.
JIRA és tervezés
Érdemes megemlíteni, hogy általában a JIRA-t használjuk feladatkezelőként, így hozzunk létre egy külön táblát ennek a projektnek, és dobjuk össze az első feladatokat:
Később visszatérünk arra, hogy mit nyújthat a JIRA és a GitHub együtt.
Automatizáljuk a projekt építését
A teszt projektünk a maven-nel épül, így az építése meglehetősen egyszerű, mindössze annyira van szükség, hogy a mvn clean package parancsot futtassuk.
Ehhez GitHub Actions segítségével létre kell hoznunk egy fájlt a repóban, amely leírja a workflow-nkat, ezt egy egyszerű yml fájlban megtehetjük, nem tudom, hogy tetszik-e nekem a „yml-ben való programozás”, de mit tegyünk - hozzunk létre egy build.yml fájlt a .github/workflow/ könyvtárban, ahol az építési lépéseket fogjuk leírni a master ágon:
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: JDK 11 beállítása
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven csomagolás
run: mvn -B clean package -DskipTests
on — ez az esemény leírása, amely alapján a szkriptünket elindítjuk.
on: pull_request / push — azt mondja, hogy ezt a workflow-t minden push-alkalommal a master ágba és pull-requests létrehozásakor kell futtatni.
Ezután a feladatok (jobs) és a végrehajtási lépések (steps) leírása jön minden feladatnál.
runs-on — itt választhatunk cél OS-t, meglepő módon akár Mac OS-t is választhatunk, de a privát repók esetében ez meglehetősen drága kényelem (linux-hoz képest).
uses lehetővé teszi más akciók újrafelhasználását, például az actions/setup-java akció segítségével beállítjuk a Java 11 környezetet.
Segítségével with Megadhatjuk azokat a paramétereket, amelyeken keresztül végrehajtjuk a műveletet; ezek lényegében az érvek, amelyeket átadunk az akciónak.
Csak el kell indítanunk a maven-t a projekt összeállításához: run: mvn -B clean package a flagot -B arra utal, hogy szükségünk van non-interactive módra, hogy a maven ne kérdezzen tőlünk semmit.
Kiváló! Mostantól minden egyes commitnál a master ágra projekt összeállítás indul.
Automatizáljuk a tesztek indítását.
Az összeállítás nagyszerű, de a valóságban a projekt gond nélkül összeállhat, de nem működhet. Ezért a következő lépés az automatizált tesztfutásra fog összpontosítani. Ráadásul, nagyon hasznos látni a tesztfutás eredményét, amikor PR-t vizsgálunk — pontosan tudjuk, hogy a tesztek átmentek, és senki sem felejtette el, hogy a merge előtt futtassa a saját ágainkat.
A teszteket indítsuk el a pull request létrehozásakor és a master ágba való merge-nél, és emellett építsünk jelentést a kódlefedettségről.
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 }}
A tesztlefedettséghez a codecov-ot használom a jacoco plugin mellett. A codecov-nak van saját akciója, de ehhez a pull-requestünkhöz token szükséges:
${{ secrets.CODECOV_TOKEN }} — egy ilyen szerkezetet még többször találkozunk, a secrets egy titokkezelési mechanizmus a GitHub-on, ahol jelszavakat/tokeneket/hosztokat/url-eket és egyéb adatokat tárolhatunk, amelyeket nem szabad nyilvánosságra hozni a kódalapban.
A secrets-hez változót hozzáadni a GitHub-repo beállításainál lehet:
A tokent a következő címen lehet megszerezni: miután bejelentkeztünk a GitHub-on, a nyilvános projekt hozzáadásához egyszerűen a következő linkre kell navigálnunk: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Adjuk hozzá a jacoco plugint a POM fájlhoz:
org.jacoco
jacoco-maven-plugin
0.8.4
prepare-agent
report
test
report
org.apache.maven.plugins
maven-surefire-plugin
2.22.2
plain
**/*Test*.java
**/*IT*.java
Most már minden pull requestünkhöz érkezik a codecov bot, és hozzáadja a lefedettségi diagramot:
Hozzáadunk egy statikus elemzőt
Nyílt forráskódú projektjeim többségében a Sonar Cloud-ot használom a kód statikus elemzésére, amit viszonylag könnyen csatlakoztathatok a travis-ci-hez. Ezért logikus lépés a GitHub Actions-ra való átállás során is ugyanazt tenni. A market actions – klassz dolog, de ezúttal egy kicsit becsapott, mert szokásból megtaláltam a szükséges actiont és beírtam a workflow-be. Kiderült, hogy a Sonar nem támogatja a Maven vagy Gradle projektek elemzését action-nél. Erről persze a dokumentációban írtak, de ki olvassa azt?!
Mivel action-nel nem lehet, ezért mvn plugin-nal fogunk dolgozni:
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: JDK beállítása
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Elemzés a SonarCloud-dal
# környezeti változók beállítása:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
# Sonar maven plugin futtatása:
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 — az alábbi módon kapható és ezt a titkosok között kell megadni. GITHUB_TOKEN — ez a GitHub által generált beépített token, amellyel a sonarcloud[bot] be tud jelentkezni a gitbe, hogy üzeneteket hagyjon a pull requestekben.
Dsonar.projectKey — a projekt neve a Sonar-ban, amit a projekt beállításaiban lehet megtekinteni.
Dsonar.organization — a GitHub-beli szervezet neve.
Készítünk egy pull requestet, és várjuk, hogy a sonarcloud[bot] megjelenjen a megjegyzések között:
Kiadás menedzsment
A build kész, a tesztek lefutottak, most már készíthetünk kiadást is. Nézzük meg, hogyan segít a GitHub Actions jelentősen leegyszerűsíteni a release management-et.
A munkahelyemen vannak olyan projektek, amelyek kódalapja a bitbucket-en található (mint a történetben: „napközben bitbucket-be írok, éjjel GitHub-ra küldöm a commitokat”). Sajnos a bitbucket nem rendelkezik beépített eszközökkel a kiadások kezelésére. Ez problémát jelent, mert minden kiadáshoz kézzel kell létrehozni egy oldalt a confluence-ben, és oda fel kell tölteni az összes új funkciót, amely a kiadásban szerepel, át kell nézni a gondolatainkat, a feladatokat a jira-ban, a commitokat a tárolóban. Sokat lehet hibázni, valamit el lehet felejteni, vagy be lehet írni azt, ami már a múltkor kiadásra került, néha egyszerűen nem egyértelmű, hogy egy pull request hova tartozik — új funkció vagy hibajavítás, vagy tesztek módosítása, vagy valami infrastruktúrális.
Hogyan segíthet nekünk a GitHub actions? Van egy remek akció — release drafter, amely lehetővé teszi a kiadási megjegyzések fájljának sablonjának beállítását, így kategóriákba sorolhatjuk a pull requesteket, és automatikusan csoportosíthatjuk őket a kiadási megjegyzések fájlban:
Példa a jelentés sablonjának beállítására (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Új Funkciók'
labels:
- 'type:features'
# ebbe a kategóriába gyűjtjük az összes PR-t, amelynek típusa:features címkéje van
- title: ' Hibajavítások'
labels:
- 'type:fix'
# hasonlóan a type:fix címkéhez, stb.
- title: ' Dokumentáció'
labels:
- 'type:documentation'
- title: ' Konfiguráció'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Változások
$CHANGES
Hozzáadunk egy scripttel a kiadás vázlatának generálásához (.github/workflows/release-draft.yml):
name: "Kiadás vázlat létrehozása"
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 }}
Minden pull request ettől a pillanattól kezdve automatikusan a kiadási megjegyzésekbe fog kerülni — varázslat!
Itt felmerülhet a kérdés: mi van, ha a fejlesztők elfelejtik megadni a címkéket a PR-ben? Akkor nem egyértelmű, hogy melyik kategóriába soroljuk, és ismét kézzel kell foglalkozni minden egyes PR-rel. E probléma megoldásához használhatunk egy másik akciót — label verifier — amely ellenőrzi a címkék meglétét a pull requesten. Ha nincs egyetlen kötelező címke sem, akkor az ellenőrzés megbukik, és erről az üzenetet látni fogjuk a pull request-en.
name: "Címke típusok ellenőrzése"
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'
Most bármely pull requestet a következő címke egyikével kell megjelölni: type:fix, type:features, type:documentation, type:tests, type:config.
Automatikus annotálás pull-requestekhez
Mivel érintettük a pull-requestekkel való hatékony munkát, érdemes megemlíteni egy olyan akciót is, mint a labeler, amely címkéket helyez a PR-re az alapján, hogy mely fájlok változtak. Például megjelölhetünk bármilyen pull-requestet mint [build], amelyben módosítások találhatóak a könyvtárban .github/workflow.
A csatlakoztatás viszonylag egyszerű:
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 }}
Szükségünk lesz egy fájlra, amely leírja a projekt könyvtárok és a pull-requestek témái közötti megfelelést:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Az automatikusan létrehozott címkék és a kötelező címkék meglétét ellenőrző akció összekapcsolása nem sikerült, a match-label egyszerűen nem hajlandó észlelni a bot által létrehozott címkéket. Úgy tűnik, egyszerűbb lenne írni egy saját akciót, amely kombinálja a két lépést. De még ilyen formában is eléggé kényelmes, kiválaszthatjuk a címkét a lista alapján a pull-request létrehozásakor.
Itt az ideje, hogy telepítsük
Több telepítési lehetőséget kipróbáltam a GitHub Actions segítségével (ssh-n keresztül, scp-vel, és docker-hub használatával), és elmondhatom, hogy valószínűleg találni fogtok módot a bináris fájlok szerverre való feltöltésére, bármilyen furcsa is legyen a pipeline.
Tetszett az ötlet, hogy az egész infrastruktúrát egy helyen tartsuk, ezért nézzük meg, hogyan lehet telepíteni a GitHub Packages-be (ez egy tárhely bináris tartalmakhoz, npm, jar, docker).
A docker image buildelésének és GitHub Packages-be való közzétételének scriptje:
név: Docker-kép telepítése
on:
push:
branches:
- 'master'
jobs:
build_docker_image:
runs-on: ubuntu-18.04
steps:
# JAR fájl építése:
- uses: actions/checkout@v1
- name: JDK 11 beállítása
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven csomag
run: mvn -B clean compile package -DskipTests
# Globális környezeti változók beállítása:
- name: Globális környezeti változó beállítása
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#*\/}"
# Docker kép építése:
- name: Kép építése és címkézése
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 bejelentkezés
run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Kép közzététele a GitHub csomag tárolójában:
- name: Kép közzététele
env:
IMAGE_NAME: $GITHUB_REPOSITORY
run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Első lépésként össze kell állítanunk a JAR fájlt az alkalmazásunkból, majd kiszámítjuk a GitHub Docker registry útvonalát és a kép nevét. Itt van néhány trükk, amellyel még nem találkoztunk:
- A következő szerkezet: echo «::set-output name=NAME::VALUE» lehetővé teszi egy változó értékének beállítását az aktuális lépésben, így azt más lépésekben is olvashatjuk.
- Egy előző lépésben beállított változó értékét a lépés azonosítóján keresztül kaphatjuk meg: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- A standard GITHUB_REPOSITORY változó tárolja a repository nevét és a tulajdonosát („owner/repo-name”). Annak érdekében, hogy ebből a szövegből eltávolítsuk mindent a repository nevén kívül, bash szintaxist használunk: ${GITHUB_REPOSITORY#*\/}
Ezután össze kell állítanunk a Docker képet:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Be kell jelentkezni a registry-be:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
És közzé kell tennünk a képet a GitHub Packages Repository-ban:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
A kép verziójának megadásához a commit SHA hash első számjegyeit használjuk — a GITHUB_SHA itt is van néhány finomság, ha nemcsak a master-be való merge során készítjük ezeket az építményeket, hanem a pull-request létrehozásának eseménye alapján is, a SHA eltérhet attól a hash-től, amit a git történetében látunk, mert az actions/checkout egyedi hash-t készít a PR-ben való kölcsönös blokkolások elkerülése érdekében.
Ha minden jól sikerült, akkor a repository Packages részében (https://github.com/antkorwin/github-actions/packages) új Docker képet fog látni:
Ott még meg lehet nézni a docker-kép verziók listáját.
Csak annyit kell tennünk, hogy beállítjuk a szerverünket, hogy működjön ezzel a registry-vel, és elindítjuk a szolgáltatás újraindítását. Arról, hogyan tegyük ezt a systemd-n keresztül, talán egy másik alkalommal mesélek.
Monitorozás
Nézzük meg egy egyszerű példát, hogyan végezhetünk health check-et az alkalmazásunkon GitHub Actions segítségével. A boot alkalmazásunkban van actuator, így az állapotának ellenőrzésére nem kell API-t írni, a lustáknak már mindent megcsináltak. Csak annyit kell tenni, hogy meghívjuk a hostot: 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"}
Minden, amire szükségünk van — egy cron alatti szerverellenőrző feladat létrehozása, és ha az nem válaszol, akkor értesítést küldünk a Telegramra.
Először nézzük meg, hogyan indíthatunk workflow-t cron segítségével:
on:
schedule:
- cron: '*\/5 * * * *'
Minden egyszerű, még alig hiszem el, hogy a GitHubon ilyen eseményeket lehet csinálni, amelyek nem illeszkednek a webhookokba. A részletek a dokumentációban találhatók:
A szerver státuszának ellenőrzését manuálisan végezzük el curl segítségével:
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"
Először elmentjük egy változóba azt, amit a szerver válasza küldött, a következő lépésben ellenőrizzük, hogy a státusz UP, és ha nem az, akkor hibával kilépünk. Ha manuálisan "megtagadjuk" az akciót, akkor exit 1 — megfelelő fegyver.
- 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 }}
A Telegramra küldött értesítést csak akkor végezzük, ha az akció a korábbi lépésben megbukott. Az üzenet küldéséhez az appleboy/telegram-action-t használjuk, arról, hogyan lehet beszerezni a bot token-jét és a chat id-ját a dokumentációban olvasható:
Ne felejtsd el beállítani a GitHub titkok között: a szerver URL-jét és a Telegram bot tokenjeit.
Bónusz track — JIRA a lusták számára
Ígéretet tettem, hogy visszatérünk a JIRA-hoz, és itt is vagyunk. Számtalanszor láttam a stand-upokon, hogy a fejlesztők elkészítettek egy funkciót, összeolvasztották a branchet, de elfelejtették átemelni a feladatot a JIRA-ba. Természetesen, ha mindez egy helyen történne, egyszerűbb lenne, de gyakorlatilag a kódot IDE-ben írjuk, a branchet a bitbucketbe vagy a GitHubba olvasztjuk be, a feladatokat pedig utána a Jirába visszük, amihez új ablakokat kell nyitnunk, néha újra be kell jelentkeznünk, stb. Amikor jól emlékszel, hogy mi a következő lépés, akkor nincs értelme feleslegesen kinyitni a táblát. Végül is, reggel a stand-upon időt kell töltenünk a feladatok táblájának aktualizálásával.
A GitHub segít nekünk ebben a rutinszerű tevékenységben, először lehetőségünk van automatikusan áthúzni a feladatokat a code_review oszlopba, amikor közzétettük a pull requestet. Mindez annyit igényel, hogy betartjuk a branchek nevére vonatkozó megállapodást:
[projekt_név]-[feladat_szám]-cím
például, ha a projekt kulcsa „GitHub Actions” lesz GA, akkor GA-8-jira-bot lehet a GA-8 feladat megvalósításához tartozó branche.
A JIRA-val való integráció az Atlassian akciókon keresztül működik, nem tökéletes, meg kell mondanom, hogy néhány közülük egyáltalán nem működött. De csak azokról fogunk beszélni, amelyek biztosan működnek és aktívan használják őket.
Először is, be kell jelentkezni a JIRA-ba az alábbi művelettel: 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 }}
Ehhez meg kell szereznünk egy tokent a JIRA-ban, hogy ezt hogyan tehetjük meg, itt le van írva:
Kivesszük a feladat azonosítóját a branch nevéből:
- 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 branch 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 "Kérlek, nevezd el a branch-ed a JIRA feladat szerint: [projekt_kulcs]-[feladat_szám]-branch_név"
exit 1
fi
echo sikeresen megtalált JIRA feladat: ${{steps.find_issue.outputs.ISSUE_ID}}
Ha a GitHub piacon keresgélünk, akkor találhatunk egy akciót erre a feladatra, de nekem meg kellett írnom ugyanazt grep segítségével a branch nevéhez, mert az Atlassian akció egyáltalán nem akart működni a projektemnél, és jobban tartottam, hogy kiderítsem, mi nem működik, mint hogy magam elvégezzem ugyanazt.
Csak át kell helyezni a feladatot a «Code review» oszlopba a pull request létrehozásakor:
- name: Feladat átállítása
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Ehhez van egy speciális cselekvés a GitHubon, amihez csak a korábbi lépésben megszerzett feladatazonosító és a JIRA-ba végzett hitelesítés szükséges.
Hasonló módon lehet áthúzni a feladatokat a mesterbe való merge során és más eseményeknél a GitHub workflow-ban. Röviden, minden a fantáziádtól és a rutinfeladatok automatizálásához való kedvtől függ.
Következtetések
Ha megnézzük a klasszikus DEVOPS diagramot, akkor lefedtük az összes lépést, kivéve talán az operálást. Gondolom, ha akarunk, találhatunk valamilyen akciót a piacon a help-desk rendszer integrálására, tehát azt mondhatjuk, hogy a pipeline alaposan sikerült, és annak használata alapján következtetéseket vonhatunk le.
Előnyök:
- A Marketplace kész cselekvésekkel minden esetre nagyon menő. A legtöbb esetben még a forrást is megtekinthetjük, hogy megértsük, hogyan oldhatunk meg hasonló feladatokat, vagy közvetlenül a GitHub tárolóban posztolhatunk feature requestet a szerzőnek.
- A célplatform kiválasztása a buildhez: Linux, mac OS, Windows – ez egy igazán érdekes funkció.
- A GitHub Packages remek dolog, hogy az egész infrastruktúra egy helyen van, kényelmes, nem kell különböző ablakok között böngészni, minden egy-két kattintásnyira van, és szépen integrálva van a GitHub Actions-szel. A docker registry támogatása a ingyenes verzióban szintén jó előny.
- A GitHub elrejti a titkokat a build naplóiban, ezért nem olyan félelmetes a jelszavak és tokenek tárolására használni. Minden kísérlet során egyszer sem láttam titkot tiszta formában a konzolon.
- Ingyenes az Open Source projektek számára
Hátrányok:
- YML, hát, nem kedvelem. Ezzel a folyamattal a leggyakoribb commit üzenetem a «fix yml format», vagy elfelejtem a tabot valahol, vagy nem a megfelelő sorba írok. Egyébként, egy vonalzó és szögmérő előtt ülni a képernyőn nem a legkellemesebb elfoglaltság.
- DEBUG, a folytatás hibakeresése commitokkal, a rebuild elindításával és a konzolra való kiírással nem mindig kényelmes, de ez inkább az a kategória, hogy «túl kényesek vagytok», megszoktátok, hogy kényelmes IDE-kkel dolgoztok, ahol bármit le lehet debuggolni.
- Akciót bármilyen nyelven írhatsz, ha becsomagolod Dockerbe, de natívan csak a Javascript támogatott. Természetesen ez ízlés kérdése, de nekem valami más tetszene a js helyett.
Emlékeztetlek, hogy a repository az összes szkripttel itt található:
A következő héten előadást fogok tartani a Heisenbug 2020 Piter konferencián. Nemcsak arról fogok beszélni, hogyan lehet elkerülni a hibákat a tesztadatok előkészítésekor, hanem megosztom a titkaimat is az adatcsomagokkal való munkához Java-alkalmazásokban!
Forrás: habr.com
