Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

2022年に試した開発ワークフロー関係の機能やツール

数えてみたら意外と数あったのでまとめます。

release-please

Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。

github.com

例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。

# .github/workflows/release-please.yml
on:
  push:
    branches:
      - main

name: release-please
jobs:
  release-please:
    runs-on: ubuntu-latest
    outputs:
      # workspaces/module_1 ディレクトリにモジュールがある想定
      module_1: ${{ steps.release.outputs['workspaces/module_1--release_created'] }}
    steps:
      - uses: google-github-actions/release-please-action@v3
        id: release
        with:
          command: manifest
          token: ${{ github.token }}
          default-branch: main
          monorepo-tags: true
  module_1:
    needs: release-please
    if: needs.release-please.outputs.module_1
    runs-on: ubuntu-latest
    steps:
      # リリース用の設定

なおrelease-please以外のリリース自動化ツールについても以前まとめてますのでよろしければ。

tfaction

めちゃくちゃ便利ですね。自分としてはTerraform使うなら必携という感じです。安全安心を計算能力で買う感じのアプローチでActions代がちょっとかさむ印象はありますが、ワークフローを工夫すれば改善できる余地がある気もしています。

suzuki-shunsuke.github.io

スクリプトの塊なので全体像の把握は難しいですが、設定を展開する部分と処理を実行する部分に別れているのだとわかればやりやすいです。GCP民はコントリビュートチャンスいろいろありそう。

version catalog (Gradle)

複数プロジェクトで利用されている依存をまとめて管理するためのファイル。GradleにもTomlが来るとはねぇという感じですが、Yamlより書きやすいのは間違いないので特に問題はないです。Kotlinのようなプログラミング言語で書く必要性はなかったと思いますし。

docs.gradle.org

例えばbuildSrcとメインのプロジェクトの双方でspotlessを使うとDependabotがPRを2つ作っちゃう問題があるのですが、version catalogを使えばきれいに解決できます。現時点ではDependabot自体がversion catalogに対応していないという問題はあるので、Renovateに切り替える必要はありますが。

あとKotlin DSLだとextra propertyやプロジェクトプロパティでの依存バージョン管理をするのがやりにくいので、Gradle 8.0以降でKotlin DSLが標準になることを踏まえても今後version catalogがメジャーになるんだと思います。

composite action (GitHub Actions)

何度か出てくる似たような処理を抽象化してinputsで処理を分けられるようにするというやつ。 複数環境にデプロイするようなワークフローとか、ちょっと凝った初期化処理が必要なワークフローとかで使いました。

https://docs.github.com/en/actions/creating-actions/creating-a-composite-action

reusable workflow (GitHub Actions)

何度か出てくる似たような処理を抽象化してinputsで処理を分けられるようにするというやつ、その2。 自分のケースだとまだ使い所がないというか、Environmentsと合わせると便利なんだろうなという理解で止まっている。

https://docs.github.com/en/actions/using-workflows/reusing-workflows

--mount=type=cache (Docker)

MavenやGradle、aptなどのインストール処理はキャッシュがあると早い。が、コンテナ環境にローカルの ~/.m2/repositories とかをCOPYするのはハードルが高い。というときに使いやすそう。

docs.docker.com

ただローカルでは恩恵を受けやすいのだろうけど、Circle CIではまだって感じらしい。ここを頑張るよりはコンテナの外でjarを作ってCOPYする方がキャッシュ容易性という点ではきれいだし、CI環境が宣言的にメンテされてればビルドの再現性という点でも充分なので、自分で使うことはあんまりないんじゃないかという気がしている。

--mount=type=secret (Docker)

GCPのApplication Default Credentialをコンテナに渡したい、というときに使えると教えてもらったやつ。 コンテナの中で ./gradlew build するときにGCSをGradle Remote Build Cacheとして利用したい、みたいなときに使った。

docs.docker.com

これもやはりコンテナの外でjarを作るやり方なら不要だけど、 type=cache よりは使いやすそう。