Často musím stavět potrubí pro budování projektů v Javě. Někdy je to open source, někdy ne. Nedávno jsem se rozhodl zkusit přesunout některá ze svých úložišť z Travis-CI a TeamCity do GitHub Actions a vzešlo z toho toto.
Co budeme automatizovat?
Nejprve potřebujeme projekt, který budeme automatizovat, uděláme malou aplikaci v Spring boot / Java 11 / Maven. Aplikační logika nás pro účely tohoto článku nebude vůbec zajímat, důležitá je pro nás infrastruktura kolem aplikace, takže nám postačí jednoduchý REST API kontrolér.
Zdroje si můžete prohlédnout zde: Všechny fáze budování potrubí se promítají do požadavků na stažení pro tento projekt.
JIRA a plánování
Stojí za zmínku, že obvykle používáme JIRA jako nástroj pro sledování problémů, takže vytvořte samostatnou nástěnku pro tento projekt a přidejte tam první problémy:
O něco později se vrátíme k tomu, co zajímavého může JIRA a GitHub nabídnout v kombinaci.
Automatizujeme montáž projektu
Náš testovací projekt je postaven přes maven, takže jeho sestavení je docela jednoduché, vše, co potřebujeme, je balíček mvn clean.
Abychom to udělali pomocí Github Actions, budeme muset v úložišti vytvořit soubor popisující náš pracovní postup, to lze provést pomocí běžného yml souboru, nemůžu říct, že bych měl rád „yml programování“, ale co můžeme dělat - uděláme to v adresáři .github/ workflow/ soubor build.yml, ve kterém popíšeme akce při sestavování hlavní větve:
name: Build
on:
pull_request:
branches:
- '*'
push:
branches:
- 'master'
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v1
- name: set up JDK 11
uses: actions/setup-java@v1
with:
java-version: 1.11
- name: Maven Package
run: mvn -B clean package -DskipTests
on — toto je popis události, při které bude náš skript spuštěn.
na: pull_request/push — označuje, že tento pracovní postup je třeba spustit pokaždé, když je proveden push na hlavní server a jsou vytvořeny požadavky na stažení.
Následuje popis úkolů (pracovních míst) a kroky provedení (kroky) pro každý úkol.
náběhy - zde můžeme vybrat cílový OS, překvapivě si můžete vybrat i Mac OS, ale na soukromých repozitářích je to dost drahé (ve srovnání s Linuxem).
použití umožňuje znovu použít jiné akce, například pomocí akce actions/setup-java nainstalujeme prostředí pro Java 11.
Prostřednictvím s můžeme specifikovat parametry, se kterými akci spustíme, v podstatě se jedná o argumenty, které budou akci předány.
Zbývá pouze spustit sestavení projektu pomocí Maven: run: mvn -B clean package vlajka -B říká, že potřebujeme neinteraktivní režim, aby se nás maven najednou nechtěl na něco ptát
Skvělý! Nyní, pokaždé, když se zavážete k hlavnímu serveru, začne sestavení projektu.
Automatické spuštění testu
Montáž je dobrá, ale ve skutečnosti lze projekt bezpečně sestavit, ale nefungovat. Dalším krokem je proto automatizace testovacích běhů. Navíc je docela pohodlné podívat se na výsledky absolvování testů, když děláte PR recenzi - určitě víte, že testy projdou a nikdo nezapomněl spustit svou pobočku, než udělal merge.
Spustíme testy při vytváření pull requestu a sloučení do masteru a zároveň přidáme vytvoření reportu o code-coverage.
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 }}
Pro pokrytí testů používám codecov ve spojení s pluginem jacoco. codecov má svou vlastní akci, ale pro práci s naším požadavkem na stažení potřebuje token:
${{ secrets.CODECOV_TOKEN }} — tuto konstrukci uvidíme vícekrát, secrets je mechanismus pro ukládání tajných informací v GitHubu, můžeme tam zapisovat hesla/tokeny/hostitelé/url a další data, která by neměla být zahrnuta do báze kódu úložiště.
Proměnnou můžete přidat do tajných klíčů v nastavení úložiště na GitHubu:
Token můžete získat na Po autorizaci přes GitHub, chcete-li přidat veřejný projekt, stačí následovat odkaz, jako je tento: /[název repo]. Lze přidat také soukromé úložiště; k tomu musíte aplikaci v Github udělit práva codecov.
Přidejte plugin jacoco do souboru 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>
Nyní robot codecov zadá každý z našich požadavků na stažení a přidá graf změny pokrytí:
Přidáme statický analyzátor
Ve většině svých open source projektů používám sonar cloud pro analýzu statického kódu, je docela snadné se připojit k travis-ci. Je to tedy logický krok při migraci na GitHub Actions udělat totéž. Akční trh je skvělá věc, ale tentokrát mě trochu zklamal, protože jsem ze zvyku našel akci, kterou jsem potřeboval, a přidal ji do pracovního postupu. Ukázalo se však, že sonar nepodporuje práci prostřednictvím akce pro analýzu projektů na maven nebo gradle. To je samozřejmě napsáno v dokumentaci, ale kdo to čte?!
Není to možné prostřednictvím akce, takže to uděláme pomocí pluginu 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 - lze získat na a musíte to zaregistrovat v tajných. GITHUB_TOKEN - jedná se o vestavěný token, který GitHub generuje, s jehož pomocí se sonarcloud[bot] bude moci přihlásit do Gitu, aby nám zanechával zprávy v požadavcích na stažení.
Dsonar.projectKey — název projektu v sonaru, můžete jej vidět v nastavení projektu.
Dsonar.organizace — název organizace z GitHubu.
Podáváme žádost o stažení a čekáme, až sonarcloud [bot] přijde do komentářů:
správa release
Sestavení bylo nakonfigurováno, testy byly spuštěny a můžeme vydat vydání. Podívejme se, jak GitHub Actions může výrazně usnadnit správu vydání.
V práci mám projekty, jejichž kódová základna je v bitbucketu (vše je jako v tom příběhu „přes den píšu na bitbucket, v noci se zavazuji na GitHub“). Bitbucket bohužel nemá vestavěné nástroje pro správu vydání. To je problém, protože pro každé vydání musíte ručně vytvořit stránku v confluence a nahodit tam všechny funkce obsažené ve vydání, prohledat paláce mysli, úkoly v jira, commity v repozitáři. Existuje mnoho šancí udělat chybu, můžete něco zapomenout nebo zadat něco, co již bylo vydáno minule, někdy prostě není jasné, co klasifikovat jako požadavek na stažení - je to funkce nebo oprava chyby, nebo editační testy, nebo něco infrastrukturního.
Jak nám mohou pomoci akce GitHubu? Je tu skvělá akce – návrhář vydání, který vám umožňuje nastavit šablonu souboru poznámek k vydání pro nastavení kategorií požadavků na stažení a automaticky je seskupit do souboru poznámek k vydání:
Příklad šablony pro nastavení sestavy (.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
Přidejte skript pro vygenerování verze konceptu (.github/workflows/release-draft.yml):
name: "Create draft release"
on:
push:
branches:
- master
jobs:
update_draft_release:
runs-on: ubuntu-18.04
steps:
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Všechny žádosti o stažení budou od nynějška automaticky shromažďovány v poznámkách k vydání – magie!
Zde může vyvstat otázka: co když vývojáři zapomenou vložit tagy do PR? Pak není jasné, do jaké kategorie to zařadit a opět to budete muset řešit ručně, s každým PR zvlášť. K vyřešení tohoto problému můžeme použít jinou akci - ověřovač štítků - kontroluje přítomnost značek v požadavku na stažení. Pokud nejsou žádné požadované značky, kontrola se nezdaří a v naší žádosti o stažení se zobrazí zpráva.
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'
Nyní musí být každý požadavek na stažení označen jednou ze značek: type:fix, type:features, type:documentation, type:tests, type:config.
Automatická anotace požadavků na stažení
Vzhledem k tomu, že jsme se dotkli takového tématu, jako je efektivní práce s pull requesty, stojí za to mluvit o takové akci, jako je labeler, vkládá značky do PR, na základě kterých byly změněny soubory. Například můžeme označit jako [build] jakýkoli požadavek na stažení, který obsahuje změny v adresáři .github/workflow.
Zapojení je celkem jednoduché:
name: "Auto-assign themes to PR"
on:
- pull_request
jobs:
triage:
runs-on: ubuntu-18.04
steps:
- uses: actions/labeler@v2
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
Potřebujeme také soubor popisující korespondenci mezi adresáři projektu a tématy žádosti o stažení:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Nepodařilo se mi spárovat akci, která automaticky umísťuje štítky do požadavků na stažení, s akcí, která kontroluje přítomnost požadovaných štítků; match-label nechce vidět štítky přidané robotem. Zdá se jednodušší napsat vlastní akci, která kombinuje obě fáze. Ale i v této podobě je použití docela pohodlné, při vytváření požadavku na stažení je potřeba vybrat štítek ze seznamu.
Je čas nasadit
Vyzkoušel jsem několik možností nasazení přes GitHub Actions (přes ssh, přes scp a pomocí docker-hub) a mohu říci, že s největší pravděpodobností najdete způsob, jak nahrát binární soubor na server, bez ohledu na to, jak křivý je váš kanál je.
Líbila se mi možnost ponechat celou infrastrukturu na jednom místě, takže se pojďme podívat na to, jak nasadit do balíčků GitHub (toto je úložiště pro binární obsah, npm, jar, docker).
Skript pro vytvoření obrazu dockeru a jeho publikování v balíčcích 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 }}"
Nejprve musíme sestavit soubor JAR naší aplikace, poté vypočítáme cestu k registru GitHub docker a název našeho obrázku. Je zde několik triků, se kterými jsme se ještě nesetkali:
- konstrukce jako: echo „::set-output name=NAME::VALUE“ vám umožňuje nastavit hodnotu proměnné v aktuálním kroku, takže ji lze číst ve všech ostatních krocích.
- hodnotu proměnné nastavené v předchozím kroku můžete získat prostřednictvím identifikátoru tohoto kroku: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Standardní proměnná GITHUB_REPOSITORY ukládá název úložiště a jeho vlastníka („owner/repo-name“). Abychom z tohoto řádku odstranili vše kromě názvu úložiště, použijeme syntaxi bash: ${GITHUB_REPOSITORY#*/}
Dále musíme vytvořit obrázek dockeru:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Přihlaste se do registru:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
A publikujte obrázek do úložiště balíčků GitHub:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Abychom uvedli verzi obrázku, používáme první číslice z hashe SHA odevzdání - GITHUB_SHA jsou zde také nuance, pokud takové sestavení provádíte nejen při sloučení do masteru, ale také podle vytvoření požadavku na stažení event, pak SHA nemusí odpovídat hash, který vidíme v historii git, protože akce action/checkout vytváří svůj vlastní jedinečný hash, aby se zabránilo zablokování akcí v PR.
Pokud vše fungovalo dobře, otevřete sekci balíčků (https://github.com/antkorwin/github-actions/packages) v úložišti a uvidíte nový obrázek dockeru:
Zde můžete také vidět seznam verzí obrázku dockeru.
Zbývá pouze nakonfigurovat náš server pro práci s tímto registrem a restartovat službu. O tom, jak to udělat prostřednictvím systemd, budu pravděpodobně mluvit jindy.
Sledování
Podívejme se na jednoduchou možnost, jak provést kontrolu stavu naší aplikace pomocí akcí GitHub. Naše spouštěcí aplikace má akční člen, takže ani nepotřebujeme psát API, abychom zkontrolovali její stav; už jsme udělali vše pro lenochy. Stačí vytáhnout hostitele: SERVER-URL:PORT/actuator/health
$ curl -v 127.0.0.1:8080/actuator/health
> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*
< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT
{"status":"UP"}
Vše, co potřebujeme, je napsat úkol pro kontrolu serveru pomocí cronu, a pokud nám náhle neodpoví, pošleme oznámení v telegramu.
Nejprve zjistíme, jak spustit pracovní postup cronu:
on:
schedule:
- cron: '*/5 * * * *'
Je to jednoduché, ani se mi nechce věřit, že v Github můžete vytvářet události, které se vůbec nehodí do webhooků. Podrobnosti jsou v dokumentaci:
Pojďme zkontrolovat stav serveru ručně 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 is failed"
exit 1
fi
echo "It's OK"
Nejprve do proměnné uložíme, co server na požadavek odpověděl, v dalším kroku zkontrolujeme, zda je stav UP a pokud tomu tak není, ukončíme s chybou. Pokud potřebujete „přetěžit“ akci rukama, pak výjezd 1 - vhodná zbraň.
- name: send alert in telegram
if: ${{ failure() }}
uses: appleboy/telegram-action@master
with:
to: ${{ secrets.TELEGRAM_TO }}
token: ${{ secrets.TELEGRAM_TOKEN }}
message: |
Health check of the:
${{secrets.SERVER_HOST}}/api/actuator/health
failed with the result:
${{ steps.ping.outputs.status }}
Odešleme do telegramu pouze v případě, že akce selhala v předchozím kroku. K odeslání zprávy používáme appleboy/telegram-action; o tom, jak získat token bota a ID chatu, si můžete přečíst v dokumentaci:
Nezapomeňte napsat do tajů na Github: URL pro server a tokeny pro telegramového robota.
Bonusová skladba - JIRA pro lenochy
Slíbil jsem, že se vrátíme do JIRA, a vrátili jsme se. Stokrát jsem pozoroval situaci na stand-upech, kdy vývojáři vytvořili funkci, sloučili větev, ale zapomněli problém přetáhnout do JIRA. Samozřejmě, kdyby se to všechno dělalo na jednom místě, bylo by to jednodušší, ale ve skutečnosti píšeme kód v IDE, slučujeme větve do bitbucketu nebo GitHubu a pak přetahujeme úkoly do Jira, k tomu potřebujeme otevřít nová okna , někdy se znovu přihlásit atd. Když si dokonale zapamatujete, co musíte udělat dál, pak nemá smysl desku znovu otevírat. Výsledkem je, že ráno ve standupu musíte trávit čas aktualizací tabulky úkolů.
GitHub nám také pomůže s tímto rutinním úkolem; pro začátek můžeme problémy automaticky přetáhnout do sloupce code_review, když odešleme žádost o stažení. Vše, co musíte udělat, je dodržovat konvenci pojmenování větví:
[имя проекта]-[номер таска]-название
pokud je například klíč projektu „GitHub Actions“ GA, pak GA-8-jira-bot by mohla být větví pro implementaci úlohy GA-8.
Integrace s JIRA funguje přes akce od Atlassianu, nejsou dokonalé, musím říct, že některé se mi vůbec neosvědčily. Probereme ale jen ty, které rozhodně fungují a jsou aktivně využívány.
Nejprve se musíte přihlásit do JIRA pomocí akce: 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 }}
Chcete-li to provést, musíte získat token v JIRA, jak to udělat, je popsáno zde:
Z názvu větve extrahujeme identifikátor úlohy:
- name: Find Issue
id: find_issue
shell: bash
run: |
echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
echo brach name: $GITHUB_HEAD_REF
echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'
- name: Check Issue
shell: bash
run: |
if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
exit 1
fi
echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}
Pokud hledáte na tržišti GitHub, můžete najít akci pro tento úkol, ale totéž jsem musel napsat pomocí grep pomocí názvu pobočky, protože tato akce od Atlassianu nechtěla na mém projektu nijak pracovat , abyste zjistili, co tam bylo špatně - déle než dělat to samé rukama.
Zbývá pouze přesunout úlohu do sloupce „Revize kódu“ při vytváření požadavku na stažení:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Na GitHubu pro to existuje speciální akce, vše, co potřebuje, je ID problému získané v předchozím kroku a autorizace v JIRA, kterou jsme provedli výše.
Stejným způsobem můžete přetahovat úkoly při slučování do hlavního serveru a další události z pracovního postupu GitHubu. Obecně vše závisí na vaší představivosti a touze automatizovat rutinní procesy.
Závěry
Když se podíváte na klasický DEVOPS diagram, pokryli jsme všechny fáze, snad kromě provozu, myslím, že když to zkusíte, najdete na trhu nějakou akci pro integraci se systémem help-desk, takže budeme předpokládat, že se potrubí otočilo být důkladný a na základě jeho použití lze vyvodit závěry.
výhody:
- Marketplace s připravenými akcemi pro všechny příležitosti, to je velmi cool. Ve většině z nich se můžete také podívat na zdrojový kód, abyste pochopili, jak vyřešit podobný problém, nebo odeslat požadavek na funkci autorovi přímo v úložišti GitHub.
- Výběr cílové platformy pro sestavení: Linux, mac os, windows je docela zajímavá funkce.
- Balíčky Github jsou skvělá věc, je pohodlné mít celou infrastrukturu na jednom místě, nemusíte procházet různými okny, vše je v okruhu jednoho nebo dvou kliknutí myší a je dokonale integrováno s akcemi GitHub. Dobrou výhodou je také podpora registru Docker v bezplatné verzi.
- GitHub skrývá tajemství v protokolech sestavení, takže jeho použití k ukládání hesel a tokenů není tak děsivé. Během všech mých experimentů jsem nikdy nebyl schopen vidět tajemství v jeho čisté podobě v konzole.
- Zdarma pro Open Source projekty
nevýhody:
- YML, no, nemám ho rád. Při práci s takovým tokem je nejčastější zpráva o odevzdání, kterou mám, „opravit formát yml“, někdy zapomenete někam umístit kartu, někdy ji napíšete na špatný řádek. Obecně platí, že sedět před obrazovkou s úhloměrem a pravítkem není nejpříjemnější zážitek.
- DEBUG, ladění toku pomocí odevzdání, spuštění přestavby a výstup na konzoli není vždy pohodlné, ale je to spíše kategorie „jste přehnaní“; jste zvyklí pracovat s pohodlným IDEA, když můžete ladit cokoliv .
- Svou akci můžete napsat na cokoli, pokud to zabalíte do Dockeru, ale nativně je podporován pouze javascript, to je samozřejmě věc vkusu, ale místo js bych preferoval něco jiného.
Dovolte mi připomenout, že úložiště se všemi skripty je zde:
Příští týden budu vystupovat s na konferenci Heisenbug 2020 Piter. Řeknu vám nejen, jak se vyvarovat chyb při přípravě testovacích dat, ale také se podělím o svá tajemství práce s datovými sadami v aplikacích Java!
Zdroj: www.habr.com