数えてみたら意外と数あったのでまとめます。
release-please
Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。
例えば↓のようなワークフローを用意すれば、モジュールごとに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代がちょっとかさむ印象はありますが、ワークフローを工夫すれば改善できる余地がある気もしています。
スクリプトの塊なので全体像の把握は難しいですが、設定を展開する部分と処理を実行する部分に別れているのだとわかればやりやすいです。GCP民はコントリビュートチャンスいろいろありそう。
version catalog (Gradle)
複数プロジェクトで利用されている依存をまとめて管理するためのファイル。GradleにもTomlが来るとはねぇという感じですが、Yamlより書きやすいのは間違いないので特に問題はないです。Kotlinのようなプログラミング言語で書く必要性はなかったと思いますし。
例えば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するのはハードルが高い。というときに使いやすそう。
ただローカルでは恩恵を受けやすいのだろうけど、Circle CIではまだって感じらしい。ここを頑張るよりはコンテナの外でjarを作ってCOPYする方がキャッシュ容易性という点ではきれいだし、CI環境が宣言的にメンテされてればビルドの再現性という点でも充分なので、自分で使うことはあんまりないんじゃないかという気がしている。
--mount=type=secret (Docker)
GCPのApplication Default Credentialをコンテナに渡したい、というときに使えると教えてもらったやつ。
コンテナの中で ./gradlew build
するときにGCSをGradle Remote Build Cacheとして利用したい、みたいなときに使った。
これもやはりコンテナの外でjarを作るやり方なら不要だけど、 type=cache
よりは使いやすそう。