Często muszę tworzyć potoki do budowy projektów w Javie. Czasami są to projekty open source, a czasami nie. Niedawno postanowiłem spróbować przenieść część moich repozytoriów z Travis-CI i TeamCity na GitHub Actions i oto, co z tego wyszło.
Co będziemy automatyzować
Na początek potrzebujemy projektu, który będziemy automatyzować, zróbmy małą aplikację na Spring Boot / Java 11 / Maven. W ramach tego artykułu nie interesuje nas logika aplikacji, ważna jest infrastruktura wokół niej, więc wystarczy nam prosty kontroler REST API.
Źródła można zobaczyć tutaj: wszystkie etapy budowy pipeline'u są odzwierciedlone w pull requestach tego projektu.
JIRA i planowanie
Warto wspomnieć, że zwykle używamy JIRA jako narzędzia do śledzenia zadań, więc stwórzmy osobną tablicę do tego projektu i dodajmy tam pierwsze zadania:
Niedługo wrócimy do tematu tego, co ciekawego można osiągnąć w połączeniu JIRA i GitHub.
Automatyzujemy budowę projektu
Nasz testowy projekt buduje się przez Maven, więc jego budowa jest dość prosta, wszystko, czego potrzebujemy, to mvn clean package.
Aby zrobić to za pomocą Github Actions, musimy stworzyć w repozytorium plik z opisem naszego workflow, można to zrobić zwykłym plikiem yml, nie mogę powiedzieć, że lubię „programowanie w yml”, ale cóż, robimy w katalogu .github/workflow/ plik build.yml, w którym opiszemy działania przy budowie gałęzi 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
włączony — to opis zdarzenia, na które nasz skrypt będzie uruchamiany.
on: pull_request / push — oznacza, że ten workflow powinien być uruchamiany przy każdym puszu do mastera i tworzeniu pull requestów.
Następnie następuje opis zadań (jobs) i kroki wykonania (steps) dla każdej zadania.
runs-on — tutaj możemy wybrać docelowy system operacyjny, co zaskakujące, możemy wybrać nawet Mac OS, ale przy prywatnych repozytoriach to dość kosztowna przyjemność (w porównaniu do linuxa).
uses pozwala na ponowne wykorzystanie innych akcji, na przykład za pomocą akcji actions/setup-java instalujemy środowisko dla Java 11.
Za pomocą with Możemy określić parametry, z którymi uruchamiamy akcję, są to zasadniczo argumenty, które będą przekazywane do akcji.
Pozostaje tylko uruchomić build projektu za pomocą Mavena: run: mvn -B clean package flaga -B informuje, że potrzebujemy trybu non-interactive, aby Maven nie zadał nam żadnych pytań
Świetnie! Teraz przy każdym commitcie do mastera, uruchamiana jest kompilacja projektu.
Automatyzujemy uruchamianie testów
Kompilacja to jedno, ale w rzeczywistości projekt może być pomyślnie skompilowany, ale nie działać. Dlatego następnym krokiem powinniśmy zająć się automatyzacją uruchamiania testów. Poza tym, wygodnie jest zobaczyć wyniki testów podczas przeglądania PR — dokładnie wiesz, że testy przeszły i nikt nie zapomniał je uruchomić przed scaleniem.
Uruchamiamy testy przy tworzeniu pull requesta i merge do mastera, a przy okazji dodamy generowanie raportu o pokryciu kodu.
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 }}
Do pokrycia testów używam codecov w połączeniu z pluginem jacoco. Codecov ma swoją akcję, ale potrzebuje tokena, aby współpracować z naszym pull requestem:
${{ secrets.CODECOV_TOKEN }} — taką konstrukcję napotkamy jeszcze nie raz, secrets to mechanizm przechowywania sekretów w GitHubie, możemy tam umieścić hasła/tokeny/homy/url i inne dane, które nie powinny być ujawniane w kodzie repozytorium.
Dodanie zmiennej do secrets można zrobić w ustawieniach repozytorium na GitHubie:
Token można uzyskać na po autoryzacji przez GitHub, aby dodać publiczny projekt, wystarczy przejść pod link w formacie: /[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.
Dodajemy plugin jacoco do pliku POM:
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
Teraz do każdego naszego pull requesta będzie wchodził bot codecov i dodawał wykres zmiany pokrycia:
Dodamy statyczny analizator
W większości swoich projektów open-source używam SonarCloud do statycznej analizy kodu, dosyć łatwo można go podłączyć do Travis CI. Dlatego to logiczny krok przy migracji na GitHub Actions, aby zrobić to samo. Marketplace akcji to całkiem fajna rzecz, ale tym razem nieco zawiódł, ponieważ z przyzwyczajenia znalazłem potrzebną akcję i wpisałem ją do workflow. Okazało się, że Sonar nie wspiera pracy przez akcję do analizy projektów na Maven lub Gradle. Oczywiście, jest o tym napisane w dokumentacji, ale kto ją czyta?!
Przez akcję się nie da, dlatego zrobimy to przez plugin 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żna go uzyskać w i trzeba go wpisać w secrets. GITHUB_TOKEN — to wbudowany token, który generuje GitHub. Dzięki niemu sonarcloud[bot] będzie mógł autoryzować się w gicie, aby zostawiać nam wiadomości w pull requestach.
Dsonar.projectKey — nazwa projektu w Sonarze, można to zobaczyć w ustawieniach projektu.
Dsonar.organization — nazwa organizacji z GitHub.
Tworzymy pull request i czekamy, aż sonarcloud[bot] pojawi się w komentarzach:
Zarządzanie wydaniami
Build został skonfigurowany, testy przeszły, można zrobić wydanie. Zobaczmy, jak GitHub Actions znacznie upraszcza zarządzanie wydaniami.
W mojej pracy mam projekty, których baza kodu znajduje się w bitbucket (wszystko jak w tej historii „w ciągu dnia piszę w bitbucket, w nocy commituję do GitHub”). Niestety, w bitbucket brakuje wbudowanych narzędzi do zarządzania wersjami. To problem, ponieważ dla każdej wersji trzeba ręcznie tworzyć stronę w confluence i umieszczać tam wszystkie funkcje, które weszły w skład wersji, przeszukiwać cztery ściany umysłu, zadania w jira, commity w repozytoriach. Zdarza się dużo błędów, można coś zapomnieć lub wpisać coś, co już zostało wydane poprzednim razem, czasami po prostu nie wiadomo, do jakiego pull requestu się odnieść — czy to jest funkcja, czy poprawka błędów, czy korekta testów, czy coś infrastrukturalnego.
Jak może nam pomóc GitHub actions? Jest świetny akcja — release drafter, pozwala ustawić szablon pliku z notatkami o wydaniu, aby skonfigurować kategorie pull requestów i automatycznie grupować je w pliku z notatkami o wydaniu:
Przykład szablonu do konfiguracji raportu (.github/release-drafter.yml):
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: ' Nowe Funkcje'
labels:
- 'type:features'
# do tej kategorii zbieramy wszystkie PR z etykietą type:features
- title: ' Poprawki Błędów'
labels:
- 'type:fix'
# analogicznie dla etykiety type:fix itd.
- title: ' Dokumentacja'
labels:
- 'type:documentation'
- title: ' Konfiguracja'
labels:
- 'type:config'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## Zmiany
$CHANGES
Dodajemy skrypt do generowania szkicu wydania (.github/workflows/release-draft.yml):
name: "Utwórz szkic wydania"
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 }}
Od tego momentu wszystkie pull requesty będą automatycznie zbierane w notatkach o wydaniu — magia!
Może pojawić się pytanie: a co jeśli deweloperzy zapomną oznaczyć etykiety w PR? Wtedy nie wiadomo, do jakiej kategorii go przypisać, i znów trzeba będzie rozwiązywać to ręcznie, z każdym PR z osobna. Aby rozwiązać ten problem, możemy skorzystać z kolejnej akcji — label verifier — sprawdza, czy w pull request znajduje się wymagane tagi. Jeśli brak jakiegokolwiek obowiązkowego tagu, weryfikacja zostanie odrzucona, a my zobaczymy powiadomienie o tym w naszym pull request.
name: "Weryfikacja etykiet typów"
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 każdy pull-request musi być oznaczony jednym z tagów: type:fix, type:features, type:documentation, type:tests, type:config.
Automatyczne anotowanie pull requestów
Skoro już poruszyliśmy temat efektywnej pracy z pull requestami, warto wspomnieć o takim działaniu jak labeler, który przypisuje etykiety w PR na podstawie tego, jakie pliki zostały zmienione. Na przykład, możemy oznaczyć jako [build] każdy pull request, w którym zachodzą zmiany w katalogu .github/workflow.
Podłączenie go jest dość proste:
name: "Automatyczne przypisywanie tematów do PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Będziemy także potrzebować pliku z opisem zgodności katalogów projektu z tematykami pull requestów:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nie udało mi się połączyć akcji automatycznie przypisującej etykiety w pull requesty oraz akcji sprawdzającej obecność obowiązkowych etykiet, ponieważ match-label nie chce widzieć etykiet przypisanych przez bota. Wydaje się, że łatwiej jest napisać własną akcję, łączącą oba etapy. Ale nawet w takiej formie korzystanie jest dość wygodne, trzeba tylko wybrać etykietę z listy podczas tworzenia pull requesta.
Czas na deploy
Wypróbowałem kilka metod wdrożenia przez GitHub Actions (poprzez ssh, scp i za pomocą docker-hub) i mogę powiedzieć, że prawdopodobnie znajdziesz sposób na wgranie binarki na serwer, niezależnie od tego, jak dziwny jest twój pipeline.
Podoba mi się pomysł trzymania całej infrastruktury w jednym miejscu, dlatego przyjrzymy się, jak zrobić deploy w GitHub Packages (to repozytorium dla zawartości binarnej, npm, jar, docker).
Skrypt budowy obrazu docker i publikacji go w GitHub Packages:
nazwa: Wdrożenie obrazu docker
w:
push:
gałęzie:
- 'master'
zadania:
budowanie_obrazu_docker:
działa-na: ubuntu-18.04
kroki:
# Buduj JAR:
- używa: actions/checkout@v1
- nazwa: ustaw JDK 11
używa: actions/setup-java@v1
z:
java-wersja: 1.11
- nazwa: Pakiet Maven
run: mvn -B clean compile package -DskipTests
# Ustaw globalne zmienne środowiskowe:
- nazwa: ustaw globalne env
id: global_env
uruchom: |
echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"
# Buduj obraz Docker:
- nazwa: Budowanie i tagowanie obrazu
uruchom: |
docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .
- nazwa: Zaloguj się do dockera
uruchom: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
# Publikuj obraz w repozytorium pakietów github:
- nazwa: Publikuj obraz
env:
IMAGE_NAME: $GITHUB_REPOSITORY
uruchom: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"
Na początek musimy zbudować plik JAR naszej aplikacji, po czym obliczamy ścieżkę do rejestru docker GitHub i nazwę naszego obrazu. Jest tu kilka sztuczek, z którymi jeszcze się nie spotkaliśmy:
- konstrukcja typu: echo «::set-output name=NAME::VALUE» pozwala ustawić wartość zmiennej w bieżącym kroku, tak aby można ją było później odczytać w pozostałych krokach.
- Aby uzyskać wartość zmiennej ustawionej w poprzednim kroku, można użyć identyfikatora tego kroku: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- W standardowej zmiennej GITHUB_REPOSITORY przechowywana jest nazwa repozytorium i jego właściciela («owner/repo-name»). Aby pozbyć się z tego ciągu wszystkiego oprócz nazwy repozytorium, użyjemy składni bash: ${GITHUB_REPOSITORY#*/}
Następnie musimy zbudować obraz docker:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Zaloguj się do rejestru:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
I opublikować obraz w repozytorium pakietów GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Aby wskazać wersję obrazu, używamy pierwszych cyfr z hasha SHA commita — GITHUB_SHA tu też ma swoje niuanse, jeżeli robisz takie kompilacje nie tylko przy merge w master, ale także z okazji tworzenia pull requestów, to SHA może nie zgadzać się z hashem, który widzimy w historii gita, ponieważ akcja actions/checkout generuje swój unikalny hash, aby uniknąć wzajemnych blokad działania w PR.
Jeśli wszystko przebiegło pomyślnie, otwierając sekcję pakiety (https://github.com/antkorwin/github-actions/packages) w repozytorium, zobaczysz nowy obraz docker:
Można tam również zobaczyć listę wersji obrazu dockerowego.
Wystarczy tylko skonfigurować nasz serwer, aby działał z tym registry i uruchomić ponowne uruchomienie usługi. Jak to zrobić za pomocą systemd, opowiem być może innym razem.
Monitoring
Zobaczmy prosty sposób, jak przeprowadzić health check naszej aplikacji przy użyciu GitHub Actions. W naszej aplikacji startowej znajduje się actuator, więc nie trzeba nawet pisać API do sprawdzania jego stanu, dla leniwych wszystko już zrobiono. Wystarczy tylko wywołać host: 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"}
Wszystko, co musimy zrobić, to napisać zadanie sprawdzające serwer w cron, a jeśli przypadkiem nie odpowie, wyślemy powiadomienie na Telegram.
Na początek zrozumiemy, jak uruchomić workflow w cron:
on:
schedule:
- cron: '*\/5 * * * *'
To proste, nawet nie wierzy się, że w GitHubie można robić takie zdarzenia, które zupełnie nie mieszczą się w webhookach. Szczegóły znajdują się w dokumentacji:
Sprawdzanie stanu serwera wykonamy ręcznie za pomocą 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 nie powiódł się"
exit 1
fi
echo "W porządku"
Najpierw zapisujemy w zmiennej to, co serwer odpowiedział na żądanie, w następnym kroku sprawdzamy, czy status to UP, a jeśli nie, to wychodzimy z błędem. Jeśli trzeba ręcznie 'zabić' działanie, to function wait_lock() — odpowiednia broń.
- 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 }}
Wysłanie powiadomienia na Telegram robimy tylko wtedy, gdy działanie nie powiodło się na poprzednim kroku. Do wysyłania wiadomości używamy appleboy/telegram-action, jak uzyskać token bota i id czatu można przeczytać w dokumentacji:
Nie zapomnij zapisać w sekretach na GitHubie: URL dla serwera i tokeny dla bota Telegram.
Bonus track — JIRA dla leniwych
Obiecałem, że wrócimy do JIRA i wróciliśmy. Wielokrotnie obserwowałem na stand-upach sytuację, gdy programiści zrealizowali funkcję, zmergowali gałąź, ale zapomnieli przenieść zadanie do JIRA. Oczywiście, gdyby wszystko odbywało się w jednym miejscu, byłoby łatwiej, ale w rzeczywistości piszemy kod w IDE, scalając gałęzie w Bitbucket lub GitHub, a zadania później przenosimy do JIRA, co wymaga otwierania nowych okien, czasem konieczności ponownego logowania itd. Kiedy dokładnie pamiętasz, co należy zrobić dalej, nie ma sensu otwierać tablicy ponownie. W rezultacie, rano na stand-upie musimy tracić czas na aktualizację tablicy z zadaniami.
GitHub pomoże nam także w tej rutynowej czynności, na początek możemy automatycznie przenosić zadania do kolumny code_review, gdy wrzucimy pull request. Wszystko, co musimy zrobić, to stosować się do ustaleń dotyczących nazewnictwa gałęzi:
[nazwa projektu]-[numer zadania]-nazwa
na przykład, jeżeli klucz projektu „GitHub Actions” to GA, to GA-8-jira-bot może być gałęzią do realizacji zadania GA-8.
Integracja z JIRA działa poprzez akcje od Atlassian, które nie są idealne — muszę powiedzieć, że niektóre z nich w ogóle nie działały u mnie. Ale omówimy tylko te, które na pewno działają i są aktywnie wykorzystywane.
Na początek musisz przejść autoryzację w JIRA za pomocą akcji: 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 }}
Aby to zrobić, musisz uzyskać token w JIRA, jak to zrobić opisano tutaj:
Wyodrębnij identyfikator zadania z nazwy gałęzi:
- 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 nazwa gałęzi: $GITHUB_HEAD_REF
echo wyodrębnione zadanie: ${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 "Proszę nazywać swoją gałąź zgodnie z zadaniem JIRA: [project_key]-[task_number]-branch_name"
exit 1
fi
echo pomyślnie znaleziono zadanie JIRA: ${{steps.find_issue.outputs.ISSUE_ID}}
Jeśli poszukać na giełdzie GitHub, można znaleźć akcję dla tego zadania, ale musiałem napisać to samo za pomocą grep w nazwie gałęzi, ponieważ ta akcja od Atlassian ani myślała działać w moim projekcie. Zrozumienie, co jest nie tak — zajmowałoby dłużej, niż zrobić to ręcznie.
Pozostaje tylko przenieść zadanie do kolumny „Code review” podczas tworzenia pull requesta:
- name: Przejście zadania
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Do tego jest specjalne działanie na GitHubie, wszystko, czego potrzebuje, to identyfikator zadania uzyskany w poprzednim kroku oraz autoryzacja w JIRA, którą wykonaliśmy wcześniej.
W ten sam sposób można przeciągać zadania podczas mergowania do mastera i w innych wydarzeniach w przepływie pracy GitHub. Generalnie wszystko zależy od twojej wyobraźni i chęci do automatyzacji rutynowych procesów.
Wnioski
Jeśli spojrzeć na klasyczną diagram DEVOPS, pokryliśmy wszystkie etapy, z wyjątkiem operate, myślę, że jeśli się postaramy, można znaleźć jakieś działanie w markecie do integracji z systemem help-desk, więc uznajmy, że pipeline jest solidny i na jego podstawie można wyciągnąć wnioski.
Zalety:
- Marketplace z gotowymi działaniami na każdą okazję to naprawdę świetna sprawa. W większości z nich można także zobaczyć źródła, aby zrozumieć, jak rozwiązać podobne zadanie lub zamieścić feature request dla autora bezpośrednio w repozytorium GitHub.
- Wybór docelowej platformy do budowy: Linux, macOS, Windows to dość interesująca funkcja.
- GitHub Packages to świetna rzecz, utrzymywanie całej infrastruktury w jednym miejscu jest wygodne, nie trzeba przeszukiwać różnych okienek, wszystko w zasięgu jednego lub dwóch kliknięć myszy i doskonale zintegrowane z GitHub Actions. Wsparcie dla rejestru dockera w darmowej wersji to także dobra przewaga.
- GitHub ukrywa sekrety w logach budowy, więc korzystanie z niego do przechowywania haseł i tokenów nie jest takie straszne. Przez cały czas eksperymentów ani razu nie udało mi się zobaczyć sekretu w czystej postaci w konsoli.
- Darmowy dla projektów Open Source
Wady:
- YML, no nie lubię go. Pracując z tym przepływem, moim najczęstszym komunikatem commit jest „naprawić format yml”, czasem zapomnę wstawić tabulator, innym razem nie napiszę na tej samej linii. Generalnie siedzenie przed ekranem z kątomierzem i linijką to nie jest najprzyjemniejsze zajęcie.
- DEBUG, odpalanie przepływu za pomocą commitów, ponownym budowaniem i wypisywaniem w konsoli nie zawsze jest wygodne, ale to bardziej kwestia „przyzwyczailiście się do luksusów”, przyzwyczailiście się do pracy z wygodnymi IDE, kiedy można debugować cokolwiek.
- Swoje akcje można napisać na czymkolwiek, jeśli zapakujesz je w Dockera, ale nativnie wspierany jest tylko JavaScript. Oczywiście to kwestia gustu, ale wolałbym coś innego zamiast JS.
Przypominam, że repozytorium ze wszystkimi skryptami znajduje się tutaj:
W przyszłym tygodniu będę występować na konferencji Heisenbug 2020 Piter. Opowiem nie tylko, jak unikać błędów przy przygotowywaniu danych testowych, ale także podzielę się swoimi sekretami pracy z zestawami danych w aplikacjach Java!
Źródło: habr.com
