Cirklar av helvetet med GitHub Actions (bygger CI/CD-pipeline för ett Java-projekt)

Jag bygger ofta pipelines för att kompilera projekt i Java. Ibland är det öppen källkod, ibland inte. Nyligen bestämde jag mig för att prova på att flytta en del av mina repo från Travis-CI och TeamCity till GitHub Actions, och här är vad jag fick ut av det.

Vad ska vi automatisera

Först behöver vi ett projekt som vi ska automatisera, låt oss skapa en liten applikation i Spring Boot / Java 11 / Maven. I den här artikeln kommer vi inte att fokusera på applikationens logik alls, det viktiga för oss är infrastrukturen runt applikationen, så en enkel REST API-kontroller räcker.

Du kan titta på källkoden här: github.com/antkorwin/github-actions alla steg i byggandet av pipeline-konceptet återspeglas i pull requests för detta projekt.

JIRA och planering

Det är värt att nämna att vi vanligtvis använder JIRA som en uppgiftsspårare, så låt oss skapa ett separat styre för detta projekt och lägga till våra första uppgifter där:

Lite senare kommer vi att återkomma till vad som kan vara intressant med kombinationen av JIRA och GitHub.

Automatisera projektets byggprocess

Vårt testprojekt kompileras med maven, så byggprocessen är ganska enkel, allt vi behöver är mvn clean package.

För att göra detta med hjälp av GitHub Actions måste vi skapa en fil i repo som beskriver vår workflow; detta kan göras med en vanlig yml-fil. Jag kan inte säga att jag gillar 'programmering i yml', men vad ska man göra - vi skapar en fil build.yml i katalogen .github/workflow/ där vi kommer att beskriva åtgärderna vid byggandet av mastergrenen:

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 — detta är beskrivningen av händelsen som ska utlösa vårt skript.

on: pull_request / push — anger att denna workflow ska köras vid varje push till master och när pull requests görs.

Sedan följer beskrivningen av uppgifterna (jobs) och stegen för att utföra (steps) för varje uppgift.

runs-on — här kan vi välja mål-OS, överraskande nog kan vi till och med välja Mac OS, men på privata repositorier är detta en ganska kostsam affär (jämfört med linux).

uses tillåter att återanvända andra actions, så exempelvis med action actions/setup-java installerar vi miljön för Java 11.

Med hjälp av with Vi kan ange de parametrar vi startar åtgärden med, i grunden är detta argument som kommer att överföras till actionen.

Det är bara att köra maven för att bygga projektet: run: mvn -B clean package flagga -B detta säger att vi behöver ett icke-interaktivt läge, så att maven inte plötsligt vill fråga oss något

Utmärkt! Nu körs projektbygget vid varje commit till master.

Vi automatiserar teststarten

Byggandet är bra, men i verkligheten kan projektet byggas framgångsrikt men ändå inte fungera. Därför behöver vi nästa steg för att automatisera testkörningen. Dessutom är det ganska praktiskt att se resultatet av testkörningen när man gör en granskning av PR — man vet exakt att testerna passerar, och ingen har glömt att köra sin gren innan man slår samman.

Vi gör teststarten vid skapandet av pull request och vid sammanslagning till master, och vi lägger också till byggandet av en rapport om code-coverage.

name: Bygg

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: konfigurera 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 }}

För testtäckning använder jag codecov i kombination med jacoco-plugin. Codecov har sin egen action, men den behöver en token för att fungera med vår pull request:

${{ secrets.CODECOV_TOKEN }} — en sådan konstruktion kommer vi att se flera gånger, secrets är en mekanism för att lagra hemligheter på GitHub, där kan vi ange lösenord/tokens/värdar/url:er och andra data som inte bör synas i kodbasen.

Man kan lägga till en variabel i secrets i inställningarna för repositoryt på GitHub:

Man kan få token på codecov.io efter inloggning via GitHub, för att lägga till ett offentligt projekt behöver man bara följa en länk av typen: GitHub användarnamn/[repo name]. Приватный репозиторий тоже можно добавить, для этого надо дать права codecov приложению в гитхабе.

Vi lägger till jacoco-plugin i POM-filen:

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

Nu kommer varje pull request att få besök av codecov-boten och lägga till en graf över ändringar i täckning:

Lägg till en statisk analysator

I de flesta av mina open source-projekt använder jag SonarCloud för statisk kodanalys, det är ganska lätt att koppla det till Travis CI. Så det är ett logiskt steg vid migrering till GitHub Actions att göra detsamma. Marknadsaktiveringen är en häftig grej, men denna gång föll det lite kort, eftersom jag av vana hittade den nödvändiga aktiviteten och skrev in den i arbetsflödet. Men det visade sig att Sonar inte stöder arbete via en åtgärd för att analysera projekt på Maven eller Gradle. Det är naturligtvis angivet i dokumentationen, men vem läser den?!

Via åtgärden går det inte, så vi gör det via mvn-plugin:

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: Ställ in JDK
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Analysera med SonarCloud
#       ställ in miljövariabler:
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
#       kör 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 — kan erhållas på sonarcloud.io och måste anges i secrets. GITHUB_TOKEN — det inbyggda token som genereras av GitHub, med vilket sonarcloud[bot] kan autentisera sig i git för att lämna meddelanden i våra pull requests.

Dsonar.projectKey — projektets namn i Sonar, kan ses i projektinställningarna.

Dsonar.organization — organisationsnamnet från GitHub.

Skapa en pull request och vänta på att sonarcloud[bot] ska komma med kommentarer:

Release management

Bygget är inställt, testerna är genomförda, det är dags att göra en release. Låt oss titta på hur GitHub Actions hjälper till att förenkla release management.

På jobbet har jag projekt vars kodbas ligger i Bitbucket (allt som i den där historien "på dagen skriver jag i Bitbucket, på natten commitar jag till GitHub"). Tyvärr saknar Bitbucket inbyggda verktyg för att hantera releaser. Det är ett problem, eftersom vi för varje release manuellt måste skapa en sida i Confluence och samla alla funktioner som ingår i releasen, granska alla resurser, uppgifter i Jira, commits i repository. Det finns många chanser att göra fel, man kan glömma något eller skriva in något som redan släpptes förra gången, ibland är det bara oklart vad man ska hänföra någon pull request till — är det en funktion, en buggfix, en testjustering, eller något infrastrukturrelaterat.

Hur kan GitHub Actions hjälpa oss? Det finns en utmärkt åtgärd — release drafter, som gör att man kan ställa in en mall för release notes, för att kategorisera pull requests och automatiskt gruppera dem i filen med release notes:

Exempel på en mall för att konfigurera rapporten (.github/release-drafter.yml):

name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
  - title: 'Nya funktioner'
    labels:
      - 'type:features'
# i denna kategori samlar vi alla PR som har etiketten type:features

  - title: 'Bugfixar'
    labels:
      - 'type:fix'
# på samma sätt för etiketten type:fix osv.

  - title: 'Dokumentation'
    labels:
      - 'type:documentation'

  - title: 'Konfiguration'
    labels:
      - 'type:config'

change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
  ## Ändringar
  $CHANGES

Vi lägger till ett skript för att generera utkastet av releasen (.github/workflows/release-draft.yml):

name: "Skapa utkastrelease"

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

Från och med nu kommer alla pull requests automatiskt att samlas i release notes — magi!

Här kan en fråga uppstå: vad händer om utvecklarna glömmer att sätta etiketter i PR? Då är det oklart vilken kategori det ska hänföras till och man får återigen gå igenom varje PR manuellt. För att åtgärda detta problem kan vi använda ännu en åtgärd — label verifier — som kontrollerar förekomsten av etiketter på pull request. Om det inte finns någon obligatorisk etikett kommer kontrollen att misslyckas och vi får ett meddelande om detta i vår pull request.

name: "Verifiera typetiketter"

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'

Nu måste varje pull request märkas med en av etiketterna: type:fix, type:features, type:documentation, type:tests, type:config.

Automatisk annotering av pull-begärningar

Eftersom vi har berört ämnet effektivt arbete med pull-begärningar, är det värt att nämna en åtgärd som kallas labeler, som sätter etiketter på PR baserat på vilka filer som har ändrats. Till exempel kan vi märka en pull-begäran som [build] om det finns ändringar i katalogen .github/workflow.

Det är ganska enkelt att koppla in det:

name: "Automatiskt tilldela teman till PR"

on:
  - pull_request

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

Vi kommer också att behöva en fil som beskriver hur projektets kataloger matchar temana för pull-begärningar:

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

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

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

theme:documentation:
  - "docs/**"

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

Jag lyckades inte kombinera åtgärden som automatiskt sätter etiketter i pull-begärningar med åtgärden som kontrollerar närvaron av nödvändiga etiketter; match-label vill inte se etiketter som sätts av boten. Det verkar enklare att skriva en egen åtgärd som kombinerar båda faserna. Men även i detta format är det ganska bekvämt att välja en etikett från listan när man skapar en pull-begäran.

Dags att deploya

Jag har testat flera alternativ för deploy genom GitHub Actions (via ssh, via scp, och med hjälp av docker-hub), och jag kan säga att ni nog kommer att hitta ett sätt att ladda upp en binär fil till servern, oavsett hur krånglig er pipeline är.

Jag gillade alternativet att ha hela infrastrukturen på ett ställe, så låt oss se hur vi kan göra deploy till GitHub Packages (detta är ett repo för binärt innehåll, npm, jar, docker).

Script för att bygga en docker-image och publicera den i GitHub Packages:

namn: Distribuera docker-bild

på:
  push:
    grenar:
      - 'master'

jobb:

  bygga_docker_bild:
    körs-på: ubuntu-18.04
    steg:

#     Bygg JAR:
      - använder: actions/checkout@v1
      - namn: ställa in JDK 11
        använder: actions/setup-java@v1
        med:
          java-version: 1.11
      - namn: Maven Paket
        kör: mvn -B clean compile package -DskipTests

#     Ställ in globala miljövariabler:
      - namn: ställa in globalt env
        id: global_env
        kör: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"

#     Bygg Docker-bild:
      - namn: Bygg och tagga bild
        kör: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - namn: Docker inloggning
        kör: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publicera bild till github paketförråd:
      - namn: Publicera bild
        env:
          IMAGE_NAME: $GITHUB_REPOSITORY
        kör: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"

Först behöver vi bygga JAR-filen av vår applikation, varefter vi beräknar sökvägen till GitHub docker-register och namnet på vår bild. Här finns några knep som vi ännu inte har stött på:

• konstruktionen av typen: echo «::set-output name=NAME::VALUE» gör att vi kan ställa in ett värde för variabeln i det aktuella steget så att den sedan kan läsas i alla andra steg.
• För att få värdet på variabeln som ställdes in i föregående steg kan vi använda identifieraren för det steget: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• I den standardvariabeln GITHUB_REPOSITORY lagras namnet på förvaret och dess ägare ("owner/repo-name"). För att klippa bort allt utom namnet på förvaret från denna sträng använder vi bash-syntax: ${GITHUB_REPOSITORY#*/}

Därefter behöver vi bygga docker-bilden:

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

Logga in i registret:

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

Och publicera bilden i GitHub Packages Repository:

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

För att ange versionen av bilden använder vi de första siffrorna från SHA-hashen av commit: GITHUB_SHA har också sina nyanser, om du gör sådana byggen inte bara vid merge till master, utan även vid händelsen av att skapa en pull-request, kan SHA:n skilja sig från hashvärdet som vi ser i git-historiken, eftersom åtgärden actions/checkout gör sin unika hash för att undvika ömsesidiga blockeringar av åtgärder i PR.

Om allt gick väl, så när du öppnar avsnittet paket (https://github.com/antkorwin/github-actions/packages) i förvaret, kommer du att se den nya docker-bilden:

Här kan du också se listan över versioner av docker-avbilden.

Det återstår bara att konfigurera vår server för att arbeta med detta register och starta om tjänsten. Hur man gör detta via systemd, får jag nog berätta om vid ett annat tillfälle.

Övervakning

Låt oss titta på ett enkelt alternativ för att göra health check av vår applikation med hjälp av GitHub Actions. I vår botapplikation finns det en actuator, så API:et för att kontrollera dess tillstånd behöver vi inte ens skriva, allt är redan färdigt för de lata. Det räcker att göra ett anrop till värden: 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"}

Det enda vi behöver göra är att skriva en uppgift för att kontrollera servern en gång i minuten, och om den inte svarar, så skickar vi en avisering till Telegram.

Först ska vi ta reda på hur man kör workflow på ett schema:

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

Det är enkelt, man kan knappt tro att man kan göra sådana händelser på GitHub som verkligen inte passar in i webhookar. Detaljer finns i dokumentationen: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Vi gör serverstatuskontrollen manuellt via 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 "hälsokontroll misslyckades"
            exit 1
          fi
          echo "Det är okej"

Först sparar vi i en variabel vad servern svarade på förfrågan, i nästa steg kontrollerar vi att status är UP och om det inte är så avslutar vi med ett fel. Om man behöver stänga ner åtgärden manuellt, så exit 1 – ett passande vapen.

  - name: skicka alert i telegram
    if: ${{ failure() }}
    uses: appleboy/telegram-action@master
    with:
      to: ${{ secrets.TELEGRAM_TO }}
      token: ${{ secrets.TELEGRAM_TOKEN }}
      message: |
        Hälsokontroll av:
        ${{secrets.SERVER_HOST}}/api/actuator/health
        misslyckades med resultatet:
        ${{ steps.ping.outputs.status }}

Vi gör sändningen till Telegram endast om åtgärden misslyckades i föregående steg. För att skicka meddelandet använder vi appleboy/telegram-action; du kan läsa i dokumentationen hur du får en bot-token och chat-ID: github.com/appleboy/telegram-action

Glöm inte att ange i GitHub-hemligheter: URL för servern och tokens för Telegram-boten.

Bonusspår – JIRA för de lata

Jag lovade att vi skulle återvända till JIRA, och vi har gjort det. Jag har hundratals gånger sett situationen på standups där utvecklarna gjort en funktion, släppt en gren, men glömt att dra uppgiften i JIRA. Självklart skulle det vara enklare om allt gjordes på ett ställe, men faktiskt skriver vi kod i en IDE, släpper grenar i Bitbucket eller GitHub, och drar sedan uppgifterna till JIRA, för detta måste vi öppna nya fönster, ibland logga in igen etc. När du perfekt minns vad som behöver göras härnäst finns det ingen mening med att öppna tavlan en gång till. I slutändan måste vi spendera tid på morgonen under standupen för att uppdatera uppgiftsbrädan.

GitHub kommer att hjälpa oss även med denna rutinuppgift, först kan vi automatiskt dra uppgifter till kolumnen code_review när vi skickar en pull-request. Allt som behövs är att följa namngivningskonventionen för grenarna:

[projektets namn]-[uppgiftsnummer]-namn

till exempel, om projektets nyckel 'GitHub Actions' är GA, så GA-8-jira-bot kan vara en gren för att genomföra uppgiften GA-8.

Integrationen med JIRA fungerar via Atlassians actions, de är inte perfekta, jag måste säga, vissa av dem har överhuvudtaget inte fungerat för mig. Men vi kommer endast att diskutera de som vi vet fungerar och som används aktivt.

Först måste du autentisera dig i JIRA med hjälp av åtgärden: 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 }}

För detta behöver du få en token i JIRA, hur detta görs beskrivs här: confluence.atlassian.com/cloud/api-tokens-938839638.html

Extrahera uppgiftens identifierare från grenens namn:

  - 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 "Vänligen namnge din gren enligt JIRA-uppgiften: [project_key]-[task_number]-branch_name"
        exit 1
      fi
      echo framgångsrikt hittad JIRA-uppgift: ${{steps.find_issue.outputs.ISSUE_ID}}

Om du söker i GitHub marketplace kan du hitta en åtgärd för denna uppgift, men jag var tvungen att skriva samma sak via grep baserat på grenens namn, eftersom denna åtgärd från Atlassian vägrade att fungera i mitt projekt, och det skulle ta längre tid att ta reda på vad som var fel än att göra det manuellt.

Det enda som återstår är att flytta uppgiften till kolumnen "Code review" när du skapar en pull request:

  - name: Övergång av ärende
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

Det finns en speciell åtgärd på GitHub för detta; allt den behöver är ID:t för ärendet som erhölls i föregående steg och autentisering i JIRA, vilket vi gjorde tidigare.

På samma sätt kan du dra över uppgifter vid sammanslagning till master, och vid andra händelser i GitHub-workflow. I princip beror allt på din fantasi och vilja att automatisera rutinprocesser.

Slutsatser

Om vi tittar på den klassiska DEVOPS-diagrammet har vi täckt alla steg, förutom operate. Jag tror, om vi anstränger oss, kan vi hitta någon åtgärd i marknadsplatsen för integration med ett help-desk-system, så vi kan anta att pipeline är grundlig och att vi kan dra slutsatser baserat på dess användning.

Fördelar:

• Marknadsplatsen med färdiga åtgärder för alla tillfällen är riktigt bra. I de flesta kan du också se källkoden för att förstå hur man löser liknande problem eller posta en funktionsförfrågan direkt till författaren i GitHub-repot.
• Valet av målplattform för byggande: Linux, macOS, Windows är en ganska intressant funktion.
• GitHub Packages är en utmärkt sak; att hålla hela infrastrukturen på en plats är praktiskt, du behöver inte surfa runt i olika fönster, allt finns inom en-till-två musknäpp, och är perfekt integrerat med GitHub Actions. Stödet för Docker-registret i gratisversionen är också en bra fördel.
• GitHub gömmer hemligheter i byggloggarna, så att använda det för att lagra lösenord och tokens är inte så hemskt. Under hela min tid med experiment har jag inte en enda gång sett en hemlighet i klartext i konsolen.
• Gratis för Open Source-projekt

Nackdelar:

• YML, jag gillar det inte. När jag arbetar med ett sådant flöde är mitt vanligaste commit-meddelande "fix yml format"; ibland glömmer man att sätta en tab eller skriver på fel rad. Så att sitta framför skärmen med en gradskiva och linjal är inte det trevligaste.
• DEBUG, att felsöka flöden med commits, återbyggnader och utskrift till konsolen är inte alltid bekvämt, men det faller mer under kategorin "ni har blivit bortskämda", då vi har vant oss vid att arbeta med bekväma IDE:er där man kan felsöka allt.
• Du kan skriva din egen action i vilket språk som helst om du packar den i Docker, men endast JavaScript stöds nativt. Självklart är det en smaksak, men jag skulle föredra något annat istället för js.

Jag påminner om att lagret med alla skript finns här: github.com/antkorwin/github-actions

Nästa vecka kommer jag att tala på med en presentation Heisenbug 2020 Piter konferensen. Jag kommer att berätta inte bara hur man undviker misstag vid förberedning av testdata, utan också dela med mig av mina hemligheter för att arbeta med datamängder i Java-applikationer!

Källa: habr.com