GitHub Actions を使用した地獄の輪 (Java プロジェクトの CI/CD パイプラインの構築)

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 で行います。このファイルには、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

on — これは、スクリプトが起動されるイベントの説明です。

オン: プルリクエスト/プッシュ — マスターへのプッシュが行われ、プル リクエストが作成されるたびに、このワークフローを起動する必要があることを示します。

以下にタスクの説明を示します (jobs) と実行ステップ (ステップ) タスクごとに。

走る - ここではターゲット OS を選択できます。驚くべきことに 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 }} — この構造は何度も見ることになりますが、シークレットは GitHub にシークレットを保存するためのメカニズムであり、そこにパスワード/トークン/ホスト/URL や、リポジトリのコード ベースに含めるべきではないその他のデータを書き込むことができます。

GitHub のリポジトリ設定でシークレットに変数を追加できます。

トークンは次の場所で取得できます codecov.io GitHub 経由で認証した後、パブリック プロジェクトを追加するには、次のようなリンクをたどるだけです。 GitHubのユーザー名/[リポジトリ名]。 プライベート リポジトリを追加することもできます。これを行うには、Github 内のアプリケーションに codecov 権限を付与する必要があります。

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 - で入手できます ソナークラウド.io そしてそれをシークレットに登録する必要があります。 GITHUB_TOKEN - これは GitHub が生成する組み込みトークンであり、これを利用して sonarcloud[bot] は Git にログインしてプル リクエストにメッセージを残すことができます。

Dsonar.projectKey — ソナー内のプロジェクトの名前。プロジェクト設定で確認できます。

Dsonar.organization — GitHub から取得した組織の名前。

プルリクエストを作成し、sonarcloud[bot] がコメントに来るのを待ちます。

リリース管理

ビルドが構成され、テストが実行され、リリースできるようになりました。 GitHub Actions によってリリース管理がどのように簡単になるかを見てみましょう。

仕事では、コード ベースが bitbucket にあるプロジェクトがあります (すべてが、「日中は bitbucket に書き込み、夜は GitHub にコミットする」という話のようなものです)。 残念ながら、bitbucket にはリリース管理ツールが組み込まれていません。 これは問題です。リリースごとに confluence でページを手動で作成し、そこにリリースに含まれるすべての機能を投入し、心の宮殿、jira のタスク、リポジトリのコミットを検索する必要があるからです。 間違いを犯す可能性はたくさんあります。何かを忘れたり、前回リリース済みのものを入力したりする可能性があります。場合によっては、プル リクエストを何に分類するかが明確ではない場合があります。機能なのか、バグ修正なのか、テストの編集なのか、それとも何かインフラ的なもの。

GitHub のアクションはどのように役立つのでしょうか? リリース ドラフターという素晴らしいアクションがあります。これを使用すると、リリース ノート ファイル テンプレートを設定してプル リクエストのカテゴリを設定し、それらをリリース ノート ファイル内で自動的にグループ化できます。

レポートを設定するためのテンプレートの例 (.github/release-draafter.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 を個別に手動で処理する必要があります。 この問題を解決するには、別のアクションであるラベルベリファイアを使用できます。これは、プルリクエストにタグが存在するかどうかをチェックします。 必要なタグがない場合、チェックは失敗し、プル リクエストにこれに関するメッセージが表示されます。

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 のいずれかのタグを付ける必要があります。

プルリクエストの自動アノテーション

プル リクエストの効果的な作業などのトピックについて触れたので、変更されたファイルに基づいて 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 の使用) を試してみましたが、パイプラインがどれほど不正であっても、バイナリをサーバーにアップロードする方法はおそらく見つかるでしょう。は。

インフラストラクチャ全体を XNUMX か所に保持するオプションが気に入ったので、GitHub パッケージ (これはバイナリ コンテンツ、npm、jar、docker のリポジトリ) にデプロイする方法を見てみましょう。

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 Docker レジストリへのパスとイメージの名前を計算します。 ここにはまだ見つかっていないトリックがいくつかあります。

• echo "::set-output name=NAME::VALUE" のような構造を使用すると、現在のステップで変数の値を設定できるため、他のすべてのステップで変数の値を読み取ることができます。
• このステップの識別子を通じて、前のステップで設定した変数の値を取得できます: ${{steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• 標準の GITHUB_REPOSITORY 変数には、リポジトリの名前とその所有者 (「owner/repo-name」) が格納されます。 この行からリポジトリの名前を除くすべてを削除するには、bash 構文 ${GITHUB_REPOSITORY#*/} を使用します。

次に、Docker イメージを構築する必要があります。

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 パッケージ リポジトリに公開します。

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

イメージのバージョンを示すために、コミットの SHA ハッシュの最初の数字を使用します (GITHUB_SHA)。マスターにマージするときだけでなく、プル リクエストの作成に従ってこのようなビルドを作成する場合は、ここにもニュアンスがあります。イベントの場合、アクション/チェックアウト アクションは PR でのデッドロック アクションを回避するために独自の一意のハッシュを作成するため、SHA は git 履歴に表示されるハッシュと一致しない可能性があります。

すべてがうまくいった場合は、リポジトリのパッケージ セクション (https://github.com/antkorwin/github-actions/packages) を開くと、新しい Docker イメージが表示されます。

そこでは、Docker イメージのバージョンのリストも確認できます。

残っているのは、このレジストリと連携するようにサーバーを構成し、サービスを再起動することだけです。 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 で Webhook にまったく当てはまらないイベントを作成できるなんて信じられません。 詳細はドキュメントに記載されています。 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 }}

前のステップでアクションが失敗した場合にのみテレグラムに送信します。 メッセージを送信するには、appleboy/telegram-action を使用します。ボット トークンとチャット ID を取得する方法については、ドキュメントを参照してください。 github.com/appleboy/telegram-action

Github にシークレットを忘れずに記入してください: サーバーの URL と電報ボットのトークン。

ボーナス トラック - 怠け者のための JIRA

JIRA に戻ると約束し、戻ってきました。 私はスタンドアップで、開発者が機能を作成し、ブランチをマージしたが、問題を JIRA にドラッグするのを忘れたという状況を何百回も観察してきました。 もちろん、これらすべてを XNUMX か所で実行できれば簡単ですが、実際には IDE でコードを記述し、ブランチを bitbucket または GitHub にマージし、タスクを Jira にドラッグします。このためには、新しいウィンドウを開く必要があります。 、時々再ログインなど。 次に何をする必要があるかを完全に覚えていれば、ボードを再度開く必要はありません。 その結果、朝のスタンドアップではタスクボードを更新するのに時間を費やす必要があります。

GitHub は、この日常的なタスクにも役立ちます。まず、プル リクエストを送信するときに、問題を code_review 列に自動的にドラッグできます。 必要なのは、ブランチの命名規則に従うことだけです。

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

たとえば、プロジェクト キー「GitHub Actions」が GA の場合、 GA-8-jira-bot GA-8 タスクを実装するためのブランチである可能性があります。

JIRA との統合は、Atlassian からのアクションを通じて機能しますが、それらは完璧ではなく、いくつかは私にとってまったく機能しなかったと言わざるを得ません。 ただし、確実に機能し、積極的に使用されているものについてのみ説明します。

まず、アクション atlassian/gajira-login を使用して JIRA にログインする必要があります。

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 マーケットプレイスで検索すると、このタスクのアクションを見つけることができますが、Atlassian からのこのアクションは私のプロジェクトではまったく機能しなかったため、ブランチの名前を使用して grep を使用して同じことを記述する必要がありました。 、何が間違っていたのかを理解するには、手で同じことをするよりも時間がかかります。

残っているのは、プル リクエストの作成時にタスクを「コード レビュー」列に移動することだけです。

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

GitHub にはこれに対する特別なアクションがあります。必要なのは、前のステップで取得した課題 ID と、上で行った JIRA での承認だけです。

同様に、マスターにマージするときにタスクや、GitHub ワークフローから他のイベントをドラッグできます。 一般に、それはすべてあなたの想像力と日常的なプロセスを自動化したいという願望にかかっています。

所見

古典的な DEVOPS 図を見ると、おそらく操作を除くすべての段階がカバーされています。試してみると、市場でヘルプ デスク システムとの統合に関する何らかのアクションが見つかると思います。そのため、パイプラインが切り替わったと仮定します。徹底的に検討し、その使用状況に基づいて結論を導き出すことができます。

長所：

• あらゆる場面に対応する既成のアクションを備えたマーケットプレイス、これは非常にクールです。 それらのほとんどでは、ソース コードを参照して同様の問題を解決する方法を理解したり、GitHub リポジトリで作成者に機能リクエストを直接投稿したりすることもできます。
• アセンブリのターゲット プラットフォーム (Linux、mac os、windows) を選択することは、非常に興味深い機能です。
• Github パッケージは優れた機能で、インフラストラクチャ全体を XNUMX か所に保管できて便利です。別のウィンドウを閲覧する必要がなく、マウスを XNUMX 回か XNUMX 回クリックするだけですべてが完結し、GitHub Actions と完全に統合されています。 無料版での Docker レジストリのサポートも良い利点です。
• GitHub はビルド ログに秘密を隠すため、GitHub を使用してパスワードやトークンを保存することはそれほど怖いことではありません。 私のすべての実験中、コンソール内でその秘密を純粋な形で見ることはできませんでした。
• オープンソースプロジェクトには無料

短所：

• YML そうですね、私は彼が好きではありません。 このようなフローで作業する場合、最も一般的なコミット メッセージは「yml 形式を修正してください」です。場合によっては、どこかにタブを置き忘れたり、間違った行にタブを記述したりすることがあります。 一般に、分度器と定規を持って画面の前に座るのは、あまり楽しい経験ではありません。
• DEBUG、コミットによるフローのデバッグ、リビルドの実行、コンソールへの出力は必ずしも便利とは限りませんが、どちらかというと「やりすぎ」の部類に属し、何でもデバッグできる便利な IDEA を使用することに慣れています。 。
• Docker でラップすれば何でもアクションを書くことができますが、ネイティブにサポートされているのは JavaScript だけです。もちろんこれは好みの問題ですが、私は js ではなく他のものを好みます。

すべてのスクリプトを含むリポジトリはここにあることを思い出してください。 github.com/antkorwin/github-actions

来週は一緒に出演します 報告 ハイゼンバグ2020ピーター会議にて。 テスト データを準備する際の間違いを避ける方法だけでなく、Java アプリケーションでデータ セットを操作する際の秘訣も共有します。

出所： habr.com