Circles of hell с GitHub Actions (изграждане на CI/CD конвейер за Java проект)

Често ми се налага да изграждам конвейер за изграждане на проекти в Java. Понякога е с отворен код, понякога не. Наскоро реших да опитам да преместя някои от моите хранилища от Travis-CI и TeamCity към GitHub Actions и ето какво излезе от това.

Какво ще автоматизираме?

Първо, имаме нужда от проект, който ще автоматизираме, нека направим малко приложение в Spring boot / Java 11 / Maven. За целите на тази статия изобщо няма да се интересуваме от логиката на приложението; инфраструктурата около приложението е важна за нас, така че един прост REST API контролер ще ни е достатъчен.

Можете да видите източниците тук: github.com/antkorwin/github-actions Всички етапи на изграждане на тръбопровод са отразени в заявките за изтегляне за този проект.

JIRA и планиране

Струва си да кажем, че обикновено използваме JIRA като инструмент за проследяване на проблеми, така че нека създадем отделна дъска за този проект и да добавим първите проблеми там:

Малко по-късно ще се върнем към това какви интересни неща могат да предложат JIRA и GitHub в комбинация.

Ние автоматизираме сглобяването на проекта

Нашият тестов проект е изграден чрез maven, така че изграждането му е доста лесно, всичко, от което се нуждаем, е пакетът mvn clean.

За да направим това с помощта на Github Actions, ще трябва да създадем файл в хранилището, описващ нашия работен процес, това може да се направи с обикновен yml файл, не мога да кажа, че харесвам „yml програмиране“, но какво можем да направим - правим го в .github/ директория workflow/ файл build.yml, в който ще опишем действията при изграждане на главния клон:

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 — това е описание на събитието, на което нашият скрипт ще бъде стартиран.

на: pull_request/push — показва, че този работен поток трябва да се стартира всеки път, когато се направи натискане към главния и се създадат заявки за изтегляне.

Следва описание на задачите (работни места) и стъпки за изпълнение (стъпки) за всяка задача.

натичане - тук можем да изберем целевата ОС, изненадващо можете да изберете дори Mac OS, но в частни хранилища това е доста скъпо (в сравнение с Linux).

употреби ви позволява да използвате повторно други действия, например, като използвате действието actions/setup-java, ние инсталираме средата за Java 11.

С помощта на с можем да посочим параметрите, с които стартираме действието, по същество това са аргументите, които ще бъдат предадени на действието.

Всичко, което остава, е да стартирате изграждането на проекта с Maven: run: mvn -B clean package флаг -B казва, че имаме нужда от неинтерактивен режим, така че Maven изведнъж да не иска да ни пита нещо

Страхотен! Сега, всеки път, когато се ангажирате с главния, изграждането на проекта започва.

Автоматизиране на тестовите стартирания

Сглобяването е добро, но в действителност един проект може да бъде сглобен безопасно, но не и да работи. Следователно следващата стъпка е автоматизирането на тестовите изпълнения. Освен това е доста удобно да гледате резултатите от преминаването на тестовете, когато правите PR преглед - знаете със сигурност, че тестовете преминават и никой не е забравил да стартира своя клон, преди да направи сливане.

Ще проведем тестове при създаване на заявка за изтегляне и ще се слеем в главния, като в същото време ще добавим създаването на отчет за покритието на кода.

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

За покриване на тестове използвам codecov заедно с плъгина jacoco. codecov има собствено действие, но се нуждае от токен, за да работи с нашата заявка за изтегляне:

${{ secrets.CODECOV_TOKEN }} — ще видим тази конструкция повече от веднъж, secrets е механизъм за съхраняване на тайни в GitHub, можем да запишем там пароли/токени/хостове/url и други данни, които не трябва да бъдат включени в кодовата база на хранилището.

Можете да добавите променлива към тайни в настройките на хранилището на GitHub:

Можете да получите жетон на codecov.io След упълномощаване чрез GitHub, за да добавите публичен проект, трябва само да следвате връзка като тази: Потребителско име на GitHub/[име на репо]. Може да се добави и частно хранилище; за да направите това, трябва да дадете права на codecov на приложението в Github.

Добавете плъгина jacoco към 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>

Сега ботът codecov ще въведе всяка от нашите заявки за изтегляне и ще добави графика за промяна на покритието:

Нека добавим статичен анализатор

В повечето от моите проекти с отворен код използвам сонарен облак за анализ на статичен код, доста лесно е да се свържете с travis-ci. Така че е логична стъпка, когато мигрирате към GitHub Actions, да направите същото. Екшън пазарът е страхотно нещо, но този път малко ме разочарова, защото по навик намерих нужното действие и го добавих към работния процес. Но се оказа, че сонарът не поддържа работа чрез действие за анализиране на проекти на maven или gradle. Разбира се, това го пише в документацията, но кой го чете?!

Не е възможно чрез действие, така че ще го направим чрез приставката 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 - може да се получи на sonarcloud.io и трябва да го регистрирате в тайни. GITHUB_TOKEN - това е вграден токен, който GitHub генерира, с помощта на който sonarcloud[bot] ще може да влиза в Git, за да ни оставя съобщения в заявки за изтегляне.

Dsonar.projectKey — името на проекта в сонара, можете да го видите в настройките на проекта.

Dsonar.организация — име на организацията от GitHub.

Правим заявка за изтегляне и чакаме sonarcloud[bot] да влезе в коментарите:

Управление на освобождаването

Компилацията е конфигурирана, тестовете са проведени и можем да направим версия. Нека да разгледаме как GitHub Actions може да направи управлението на версиите много по-лесно.

На работа имам проекти, чиято кодова база е в bitbucket (всичко е като в онази история „Пиша в bitbucket през деня, ангажирам се с GitHub през нощта“). За съжаление bitbucket няма вградени инструменти за управление на версиите. Това е проблем, защото за всяко издание трябва ръчно да създадете страница в сливане и да хвърлите всички функции, включени в изданието, да търсите в дворците на ума, задачи в jira, ангажименти в хранилището. Има много шансове да направите грешка, можете да забравите нещо или да въведете нещо, което вече е било пуснато миналия път, понякога просто не е ясно какво да класифицира заявка за изтегляне - дали е функция или корекция на грешка, или тестове за редактиране, или нещо инфраструктурно.

Как действията на GitHub могат да ни помогнат? Има страхотно действие - проектант на изданието, което ви позволява да зададете шаблон на файл с бележки за изданието, за да настроите категории заявки за изтегляне и автоматично да ги групирате във файла с бележки за изданието:

Примерен шаблон за настройка на отчет (.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

Добавете скрипт за генериране на чернова на издание (.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 }}

Всички заявки за изтегляне отсега нататък ще се събират автоматично в бележки за изданието - магия!

Тук може да възникне въпросът: какво ще стане, ако разработчиците забравят да поставят тагове в PR? Тогава не е ясно в коя категория да го поставите и отново ще трябва да се справяте ръчно, с всеки PR поотделно. За да коригираме този проблем, можем да използваме друго действие - label verifier - той проверява за наличие на тагове в заявката за изтегляне. Ако няма задължителни тагове, тогава проверката ще бъде неуспешна и ще видим съобщение за това в нашата заявка за изтегляне.

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'

Сега всяка заявка за изтегляне трябва да бъде маркирана с един от етикетите: type:fix, type:features, type:documentation, type:tests, type:config.

Автоматично анотиране на заявки за изтегляне

Тъй като засегнахме такава тема като ефективна работа с заявки за изтегляне, струва си да говорим за такова действие като labeler, той поставя тагове в PR въз основа на това кои файлове са променени. Например, можем да маркираме като [build] всяка заявка за изтегляне, която съдържа промени в директорията .github/workflow.

Свързването му е съвсем просто:

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

Нуждаем се също от файл, описващ съответствието между директориите на проекта и темите на заявката за изтегляне:

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

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

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

theme:documentation:
  - "docs/**"

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

Не успях да сдвоя действието, което автоматично поставя етикети в заявки за изтегляне, с действието, което проверява наличието на необходими етикети; match-label не иска да вижда етикетите, добавени от бота. Изглежда по-лесно да напишете собствено действие, което съчетава и двата етапа. Но дори и в тази форма е доста удобно за използване; трябва да изберете етикет от списъка, когато създавате заявка за изтегляне.

Време е за разгръщане

Опитах няколко опции за внедряване чрез GitHub Actions (чрез ssh, чрез scp и с помощта на docker-hub) и мога да кажа, че най-вероятно ще намерите начин да качите двоичния файл на сървъра, независимо колко крив е вашият конвейер е.

Хареса ми опцията за запазване на цялата инфраструктура на едно място, така че нека да разгледаме как да разположим пакети в GitHub (това е хранилище за двоично съдържание, npm, jar, docker).

Скрипт за създаване на докер изображение и публикуването му в 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 }}"

Първо, трябва да изградим JAR файла на нашето приложение, след което изчисляваме пътя до докерския регистър на GitHub и името на нашето изображение. Тук има няколко трика, на които все още не сме се натъкнали:

• конструкция като: echo “::set-output name=NAME::VALUE” ви позволява да зададете стойността на променлива в текущата стъпка, така че след това да може да бъде прочетена във всички останали стъпки.
• можете да получите стойността на променливата, зададена в предишната стъпка чрез идентификатора на тази стъпка: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• Стандартната променлива GITHUB_REPOSITORY съхранява името на хранилището и неговия собственик („owner/repo-name“). За да изрежем всичко от този ред с изключение на името на хранилището, ще използваме bash синтаксис: ${GITHUB_REPOSITORY#*/}

След това трябва да изградим докер изображението:

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

Влезте в регистъра:

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

И публикувайте изображението в GitHub Packages Repository:

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

За да посочим версията на изображението, използваме първите цифри от SHA хеша на комита - GITHUB_SHA тук също има нюанси, ако правите такива компилации не само при сливане в master, но и според създаването на заявка за изтегляне събитие, тогава SHA може да не съответства на хеша, който виждаме в хронологията на git, тъй като действието action/checkout прави свой собствен уникален хеш, за да се избегнат блокиращи действия в PR.

Ако всичко върви добре, отваряйки секцията с пакети (https://github.com/antkorwin/github-actions/packages) в хранилището, ще видите ново изображение на докер:

Там можете също да видите списък с версии на докер изображението.

Остава само да конфигурираме нашия сървър да работи с този регистър и да рестартираме услугата. Вероятно ще говоря за това как да направя това чрез systemd друг път.

мониторинг

Нека да разгледаме една проста опция за това как да направим проверка на състоянието на нашето приложение с помощта на GitHub Actions. Нашето приложение за зареждане има задвижващ механизъм, така че дори не е необходимо да пишем API, за да проверим състоянието му; вече сме направили всичко за мързеливите. Просто трябва да издърпате хоста: 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"}

Всичко, от което се нуждаем, е да напишем задача за проверка на сървъра с помощта на cron и ако изведнъж не ни отговори, тогава ще изпратим известие чрез телеграма.

Първо, нека разберем как да стартираме работен процес на cron:

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

Просто е, дори не мога да повярвам, че в Github можете да създавате събития, които изобщо не се вписват в webhooks. Подробностите са в документацията: help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

Нека проверим състоянието на сървъра ръчно чрез 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"

Първо записваме в променлива това, което сървърът е отговорил на заявката, в следващата стъпка проверяваме дали състоянието е UP и ако това не е така, излизаме с грешка. Ако трябва да „затрупате“ действие с ръцете си, тогава изход 1 - подходящо оръжие.

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

Изпращаме до telegram само ако действието е неуспешно при предишната стъпка. За да изпратим съобщение, ние използваме appleboy/telegram-action; можете да прочетете как да получите токен за бот и идентификатор за чат в документацията: github.com/appleboy/telegram-action

Не забравяйте да напишете в тайните на Github: URL за сървъра и токени за бота за телеграма.

Бонус песен - JIRA за мързеливите

Обещах, че ще се върнем в JIRA и се върнахме. Стотици пъти съм наблюдавал ситуация при изправяне, когато разработчиците са направили функция, сляли са клон, но са забравили да преместят проблема в JIRA. Разбира се, ако всичко това беше направено на едно място, би било по-лесно, но всъщност ние пишем код в IDE, сливаме клонове в bitbucket или GitHub и след това плъзгаме задачите в Jira, за това трябва да отворим нови прозорци , понякога влизайте отново и т.н. Когато си спомните перфектно какво трябва да направите след това, тогава няма смисъл да отваряте дъската отново. В резултат на това на сутринта при изправяне трябва да отделите време за актуализиране на таблото със задачи.

GitHub също ще ни помогне в тази рутинна задача; като за начало, можем да плъзгаме проблеми автоматично в колоната code_review, когато подадем заявка за изтегляне. Всичко, което трябва да направите, е да следвате конвенцията за именуване на клонове:

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

например, ако ключът на проекта „GitHub Actions“ е GA, тогава GA-8-jira-bot може да бъде клон за изпълнение на задачата GA-8.

Интеграцията с JIRA работи чрез действия от Atlassian, те не са перфектни, трябва да кажа, че някои от тях изобщо не работят за мен. Но ние ще обсъдим само тези, които определено работят и се използват активно.

Първо трябва да влезете в JIRA, като използвате действието: 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 }}

За да направите това, трябва да получите токен в JIRA, как да направите това е описано тук: confluence.atlassian.com/cloud/api-tokens-938839638.html

Извличаме идентификатора на задачата от името на клона:

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

Ако търсите в пазара на GitHub, можете да намерите действие за тази задача, но аз трябваше да напиша същото, използвайки grep, използвайки името на клона, защото това действие от Atlassian не искаше да работи по моя проект по никакъв начин , за да разберете какво не е наред там - по-дълго, отколкото да правите същото нещо с ръцете си.

Всичко, което остава, е да преместите задачата в колоната „Преглед на кода“, когато създавате заявка за изтегляне:

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

Има специално действие за това в GitHub, всичко, от което се нуждае, е идентификаторът на проблем, получен в предишната стъпка, и разрешението в JIRA, което направихме по-горе.

По същия начин можете да плъзгате задачи при сливане в главния и други събития от работния процес на GitHub. Като цяло всичко зависи от вашето въображение и желание за автоматизиране на рутинните процеси.

Данни

Ако погледнете класическата диаграма на DEVOPS, ние сме покрили всички етапи, с изключение може би на операцията, мисля, че ако опитате, можете да намерите някакво действие на пазара за интеграция със системата за помощ, така че ще приемем, че тръбопроводът се обърна трябва да бъде задълбочен и да могат да се правят заключения въз основа на употребата му.

плюсове:

• Пазар с готови действия за всички случаи, това е много готино. В повечето от тях можете също да разгледате изходния код, за да разберете как да разрешите подобен проблем или да публикувате заявка за функция до автора директно в хранилището на GitHub.
• Изборът на целевата платформа за сглобяване: Linux, mac os, windows е доста интересна функция.
• Github Packages е страхотно нещо, удобно е да поддържате цялата инфраструктура на едно място, не е нужно да сърфирате през различни прозорци, всичко е в радиус от едно или две кликвания на мишката и е идеално интегрирано с GitHub Actions. Поддръжката на регистър на Docker в безплатната версия също е добро предимство.
• GitHub крие тайни в регистрационни файлове за изграждане, така че използването му за съхраняване на пароли и токени не е толкова страшно. По време на всичките си експерименти никога не успях да видя тайната в чистата й форма в конзолата.
• Безплатно за проекти с отворен код

против:

• YML, добре, не го харесвам. Когато работя с такъв поток, най-често срещаното съобщение за ангажиране, което имам, е „коригиране на yml формат“, след което забравяте да поставите раздел някъде или го пишете на грешен ред. Като цяло седенето пред екран с транспортир и линийка не е най-приятното изживяване.
• DEBUG, отстраняване на грешки в потока с ангажименти, стартиране на повторно изграждане и извеждане към конзолата не винаги е удобно, но е по-скоро от категорията „прекалявате“; свикнали сте да работите с удобна IDEA, когато можете да дебъгвате всичко .
• Можете да напишете действието си върху всичко, ако го обвиете в Docker, но само javascript се поддържа първоначално, разбира се, това е въпрос на вкус, но бих предпочел нещо друго вместо js.

Нека ви напомня, че хранилището с всички скриптове е тук: github.com/antkorwin/github-actions

Следващата седмица ще участвам с доклад на конференцията Heisenbug 2020 Piter. Ще ви кажа не само как да избегнете грешки при подготовката на тестови данни, но и ще споделя моите тайни за работа с набори от данни в Java приложения!

Източник: www.habr.com