Kengo's blog

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

Threaddump, JFR, JMC周りの知識のアップデート

久々に古い知識を整理していて、けっこう更新されているものが多いのでここにまとめる。

JDK Mission Control (JMC)

JMCはOracleのウェブサイトからダウンロードできる。

標準ではOS標準のロケールが利用される。UIを日本語化する場合は jmc.iniuser.language システムプロパティを設定する。これはJVMに渡す設定なので必ず -vmargs よりも後ろに書く(Eclipseの設定と同じ)。

-Duser.language=ja

利用するJVMは jmc.ini-vm システムプロパティを設定する。これはJVM起動前に使うので -vmargs よりも前に書く。

-vm
C:\Program Files\Java\jdk-17.0.7.7\bin\javaw.exe

ThreaddumpとJFR

昔はThreaddumpファイルを複数取ってIBM Thread Dump Analyzerなどで解析していたが、今ならJFRファイルにスレッドダンプの情報が含まれるためJFRを取得すれば充分そう。

JMCで取得したJFRファイルには、期間中のスレッドダンプの情報が含まれている

JFRファイルはJMCで取得するのが一番手軽。

Gradle用のGitHub Actions勘どころ(2023年夏)

前回書いたのがもう4年前でビビったのと、最近いろいろ進展があったのでまとめてみます。

actions/setup-java の依存キャッシュを使わない

これ自分が実装した機能なのでホント申し訳ないんですけど、今なら gradle/gradle-build-action を使ったほうが良いです。 利点は公式が説明しているので読んどいてください。

github.com

spotlessApplyして差分が出たらSuggest Changeする

reviewdogが action-suggester という素敵なアクションを提供しています。GitHub Actionsでフォーマッタを実行して差分ができた状態でこのアクションを実行すると、GitHub Pull RequestのSuggest Change機能を使ってフォーマットを提案してくれます。

github.com

フォーマット適用箇所が多いと手元で ./gradlew spotlessApply したほうが早いなってケースもまぁあるとは思うんですが、やって損は無さそうです。 もちろんSpotlessに限らずktlintやPrettierのような他のフォーマッタでも利用できます。

まとめ

だいたいこんな感じじゃないですかね。リリース自動化には release-please とか semantic-release とかお好きなソリューションをご利用いただければと思います。

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read # actions/checkoutのために必要
      pull_requests: write # reviewdog/action-suggesterのために必要
    steps:
      - uses: actions/checkout@v3
      - uses: gradle/wrapper-validation-action@v1
      - uses: actions/setup-java@v3
        with:
          distribution: microsoft
          java-version: 17 # toolchainで指定したバージョンと同じものを使う
      - uses: gradle/gradle-build-action@v2
        with:
          arguments: spotlessApply build --scan
      - uses: actions/upload-artifact@v3
        if: always()
        with:
          name: Gradle reports
          path: build/reports
      - uses: reviewdog/action-suggester@v1
        if: github.event_name == 'pull_request'
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          tool_name: spotless

またワークフロー最適化の観点ではGradleのRemote Build Cacheが非常に効果的です。勤め先ではgradle-gcs-build-cacheを使ってGoogle Cloud Storageを活用した最適化を行っています。

両利きの経営を読んだ

両利きの経営(増補改訂版)―「二兎を追う」戦略が未来を切り拓くを読みました。自分の15年間の社会人経験は探索と深化が半々という感じだったこともあり、マネジメントに加えて現場の人間の感覚でも楽しく読むことができました。

この本の結論はとても単純で、おそらくA4用紙1枚にまとまると思います。また言っていることには特に驚きはないので、うんそりゃそうだよねという感想で自分が流してしまいそうだなという直感がありました。ので自分の言葉でまとめて記憶の定着を狙おうと思います。

両利きの経営、できなくて誰が困るのか

両利きの経営ができないとビジネスが先細ってやがて食えなくなる、それ自体は別に自然であり、悪いことでもないはずです。経営者としてはたまったものではないでしょうが、従業員は次の職場でまた深化を極めていくこともできるでしょう。

私が読み始めたころは自分がERPベンダ経験者ということもあり、潰れたらインフラと化したサービスが継続できなくなると考えて、現存する顧客に対しての責任から両利きの経営を目指そうという話だと思ったんですね。ただ「カネボウはとっとと繊維から撤退すればよかったのに」などの描写から、本書の問題意識はそうではなさそうです。あくまでも法人が存続することに主眼が置かれています。

株主に対する責任であるとか、従業員の雇用を守るであるとか、激動の時代に誰も探索しなかったらほとんどの企業が破綻してしまうなどの問題意識もありますが。この本を読んでなるほどと思ったのは、両利きの経営は「大企業の組織能力や資源、顧客基盤を持ったスタートアップ」という機会を生み出す経営手法だということです。時代のニーズに応えるべく生まれたスタートアップが応えられないまま潰れていくのはよくありますし、より体力のある大企業がイノベーションに挑戦することは、社会貢献の観点からも重要な経営手法でもあるのでしょう。

のでできないと困るというよりは、できることで大企業が新たな存在価値を生み出せる経営手法だという認識を持ちました。

組織がひとつの目標に向かって動く、ときの「組織」と「目標」の捉え方

この本では深化する人と探索する人との間に適度な距離感を持たせることの必要性が語られています。「適度な」というのは、近すぎても遠すぎてもだめだということです。近すぎると深化のためのベストプラクティスや運用の工夫が探索を殺してしまいますし、遠すぎると探索が必要な資源や支援を得ることができません。私の経験を振り返っても、こういう問題は確かにあると思いました。

この本の例ではハイアールの小微(シャオウェイ)のような独立企業やHPの準部門の例が紹介されていますが、一貫しているのはそれぞれの組織が独立した目標や運用を抱えている一方で、すべての組織に共通する価値観・文化があるという点でしょう。各々の組織で直近の目標ややっていることは違っていても、企業体としての存在意義が一緒なのでひとつのまとまりとして存続し協力しあうことができると理解しました。つまり存在意義を持つ企業体の中に、目標を持つ組織が入れ子になって存在している形です。組織の間には協力関係はあっても従属関係はなさそうです。

これを普通に運用すると、組織を束ねる上級幹部はとても仕事がしにくいと思いました。なぜなら:

  • 自分のところの工数や資源を他の「組織」に貸す必要があるが、そのリターンが見えないことが多い(自分の成果を犠牲にしてほか組織の成果に賭けることを意味する)
  • 特に深化の組織は持ち出しが多く、顧客や市場からのプレッシャーと板挟みになることが容易に想像できる
  • 深化の組織ではその部下から「探索の組織が自由気ままにやっているが自分は規律のもとに数字を追いかけている」という不満が出てきそう
  • 探索の組織でも同様に、安定した深化の組織を横目に「売上が上がらない、結果が出ない」ことに対するプレッシャーと向き合わなければならない

この本で出している解決策は「上級幹部の評価を自部門の成績で行わない」こと、すなわち企業体としての成績を持って評価することなのですが。責任を負うものと評価対象がねじれていて本当に機能するのか(他部門の悪状況に引っ張られている場合に上級幹部が転職を検討しそう)とか、じゃぁその下の管理層はどう評価するのか?とか考えると、やはり一筋縄では行かないですよね。上級幹部の下に深化と探索の両部門を置いて上級幹部の裁量でよしなにやってくれ、ということにする誘惑はけっこうありそうですが、それでは失敗するというのが第8章のハヴァスの事例から明らかなので、企業体として向き合わなければなりません。

考えられる最善は、上級幹部が人事評価の裁量を持ったうえで、他の組織に資源を貸し出したことを前提に本業の成績を持って部下を評価する……というものでしょうか。不満や不安も上級幹部が粘り強いコミュニケーションで自組織内で解消させる必要があります。これも言うのは簡単だがというやつで、上級幹部に人徳や公平性,タフネスといった超人性を求める運用になりそうです。

まとめると、この本では「組織を入れ子構造にすることで、存在意義や組織能力などの共有を実現しつつ運用や目標は分けると」いう矛盾を管理可能な形に落とすことを推奨しています。 この矛盾を維持するにはCEOや上級幹部の献身が欠かせません。特に組織(我々)という主語がコンテキストによって変わるであろうことを考えると、上級幹部にかかる部下への説明責任は非常に大きいものと感じました。マイシスの事例の「我々は800万ドル削減する必要がある、ただし探索組織の予算には手を付けない」が象徴的で、都合のいいときだけ一心同体だと言いやがってみたいな反応は普通に出てきそうだなと思います。この問題こそが両利きの経営が難しい理由であり、優秀なトップひとりではなく上級幹部を巻き込んで組織を作っていく必要性を強く裏付けるものだと思いました。

上級幹部ではない従業員として何ができるのか

やっぱり気になるのはここなんですが、直属の上級幹部ときちんと話をして両利きの経営を意識してもらう、くらいしかできることがない気がします。トップが変わったときに探索部隊をどうするか、深化と探索のバランスを考える人なのかを見る上ではこの本が紹介する知識や事例は役に立つと思いますが、その結果探索を縮小・停止する人だなと判明したときに、それを覆すのはほぼ無理ですよね。その人が入った時点で既定路線のはずなので。

ので自分が深化を極めたいのか、探索で結果を出したいのか、両利きの経営を実践するリーダーとして伸びていきたいのかを日頃から考えておいて、深化や探索のバランスが変わったらそのシグナルを早期にキャッチして動いていく、しかない気がします。

あとは深化と探索は異なるものでそもそも相容れないのだ、ということを頭に入れておくとコミュニケーションがやりやすい局面はありそうですね。多様性多様性と言われますが、何がどう多様でコミュニケーション上の要配慮点はどこかを知っておくだけでも助かることは多いので。深化は厳しいんだ、探索は心細いんだ、ということをざっくり踏まえておくだけでも、同僚の仕事を知って尊敬する機会はすごく増えると思います。

Cloud RunがImage not foundと言ったときの原因事例集

Cloud Runはとても便利なのですが、エラーメッセージがわかりにくいことがあります。特にデプロイしたときに遭遇するこちらのエラーが厄介です:

ERROR: (gcloud.run.deploy) Image 'asia-northeast1-docker.pkg.dev/foo/bar/baz' not found.

コンテナを引っ張ってこれなかったときは原因が何であれこのメッセージだけ残してデプロイが失敗するので、自分で切り分けなければなりません。ここ数ヶ月で複数の原因に遭遇したので記録を残します。

指定したタグを持つコンテナがない

docker build はしたけど docker push はしてなかったケース。見つからなかったのは指定したタグを持つイメージなのですが、エラーにはアクセス先レジストリそのものが見つからなかったかのように出てくるので要注意です。

Cloud Run Service Agentに権限がない

公式にはこちらのページで説明されています

project-aのCloud Runから他のプロジェクトproject-bにあるArtifact RegistryやContainer Registryからコンテナを引っ張ってくるときに、project-aのCloud Run Service Agentに適切な権限がないと失敗します。なおCloud Run Service Agentは service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com という名前を持っています。

Artifact RegistryであればArtifact Registry Readerロールが、Container RegistryであればStorage Object Viewerロールが必要になります。

イメージのマニフェストがおかしい

docker/build-push-action を導入したときに遭遇しました。docker/setup-buildx-actionと組み合わせると application/vnd.oci.image.index.v1+json media typeを持つイメージにタグが打たれるようになり、これをCloud Runは扱えないようです。イメージが使えるものだということは docker run で確認したし、公式によるとOCI image formatはサポートしているようなのですが。

docker/build-push-action 単体だと docker build 時と同様に application/vnd.docker.distribution.manifest.v2+json media typeを持つイメージにタグが打たれるため、Cloud Runでも扱えるイメージができます。

2023/01/23更新

こちらはbuildx 0.10の挙動変更による影響でした。

github.com

対策としては docker/build-push-action の設定に provenance: false を追加することが推奨されています。

Maven4の動向メモ

Maven 4は2年近く前から開発されていて、最近alphaバージョンがリリースされています。自分がMavenを使うことは殆ど無いとは思うのですが、傾向だけでも把握しておきたくてリリースノートやメーリングリストに潜ってみました。

ざっと見た感じ、Mavenでマルチモジュールビルドをしている人や、Maven向けにプラグインや拡張を提供している人は動向を追ったほうが良さそうです。既にGradleに移行した人はあまり気にしなくて良いでしょう。

マルチモジュール周りの改善

以下のサイトで解説されています。他にも親POMのバージョンを記入しなくて済むとか、依存解決周りの改善が多そうです。

maarten.mulders.it

プロジェクト定義に変更を加えつつ、古いMavenからも使えるようにしたい

MNG-6656動画で基本設計が説明されているようです。POM 4.0.0の配布を継続しつつ、ビルド時には新しいプロジェクトオブジェクトモデルを使いたいようですね。ただXSDファイルはまだ https://maven.apache.org/xsd/ では公開されてなさそうでした。

Gradleが配布時にPOM 4.0.0に加えてメタデータを添付しているのと逆で、POM 4.0.0の定義に収まるように情報を削ぎ落として互換性を確保する感じと理解しました。POM 4.0.0という枠を維持するということは、例えばGradleがcompileをapiとimplementationに分けてABIの概念を持ち込んだような破壊的な変更はあまり考えていなさそうですが、少なくとも新機能を入れることはやりやすくなるでしょう。

Maven Wrapper

4.0で wrapper ライフサイクルが導入され、 mvn wrapper:wrapper ではなく mvn wrapper で実行できるようになるようです。 Maven Wrapper 3.1.1 のドキュメントに以下の記載がありました:

wrapper:wrapper is the default goal, invoked during the wrapper phase in Maven 4. It downloads and unpacks the maven-wrapper distribution,

ちなみに「3.7.0から入る」という古い情報もありますが、リリースノートによると3.7.0は廃止になって3.7の新機能は4.0に入れることになったそうです。

とはいえMaven 3には wrapper ライフサイクルが無いだけで wrapper プラグインの公式化は完了しています。よって mvn wrapper:wrapper がMaven3でも既に通りますので、実用上の問題はないと思います。

古い”API”のサポート中止

Maven 3.0 またはこれよりも古いバージョンのAPIを利用したプラグインのサポートをやめたい、という話が出ているようです。

github.com

個人的にはMavenにAPIなんて今までなかったよねという話がちょっと面白かったです。maven-plugin-apiというパッケージは存在するのですが、ちょっと複雑なことをするとすぐに実装詳細であるmaven-coreに依存する必要性が出てくるという話ですね。

実際alphaリリースには既存のプラグインが動かなくなる問題も報告されていて、publicなクラスを積極的に削除しているのは間違いないようです。プラグインや拡張を提供している人は、alphaはともかくbetaとかRelease Candidateとかが出てきたタイミングで動作確認をしたほうが良いかもしれません。

パッケージなメガベンチャーから医療機関向けサービスを提供するスタートアップに転職して6ヶ月して感じたこと

いよいよ試用期間が終わりまして、ドメイン知識はともかく同僚の働き方はだいぶ掴めてきた気がします。6ヶ月何をやっていたかは会社の方のブログに書いたので、こちらでは感じたことを書いておきます。なお入社2ヶ月時点での所感を別の記事に記載しています

文脈

  • 人事給与,会計や購買管理といったERPをメインとしたパッケージベンダーから、医療機関向けERPを提供するスタートアップに転職した
  • SaaSを製品ラインナップに加えようという活動に従事した経験があるので、パッケージとウェブサービスと両方それなりに知っているつもりだった
  • 製品開発、製品運用、プロジェクトマネジメントないしピープルマネジメントはわりとわかっているつもりだった

ウェブサービスとパッケージはやはり大きく違うという話

ウェブサービスのほうがサポートバージョンを絞って効率よく開発できる、動作環境を掌握できるので細かいサポートが不要になるといった違いはまぁ知っていたとおりでした。古いミドルウェアやOS、明らかに少ないメモリみたいなパッケージあるあるに心を砕く必要性が少なくなったのはとてもやりやすいです。

ログやメトリクスを採ることのハードルが下がったのもやりやすく、仮設が検証しやすいということは即機能の成長速度に反映されるわけで、製品づくりのハードルも大きく下がったと思います。

一方で各お客様固有の環境は引き続き存在しています。医療機関はその内部に複雑なネットワーク構造を持っていることが多いようで、お時間のある方はぜひ事例がいくつか載っている月刊新医療 2022年11月号を見ていただきたいのですが。こういった多様かつ複雑なユーザ事情を踏まえてサービスを提供するのは難しいなと思う機会が多いです。

しかも連携先システムが多い!既存システムはもちろん、オンライン資格確認や電子処方箋のような新システムもどんどん入ってくるわけで、これらの考慮がいるという点で純粋なウェブアプリケーションではありません。こうした固有環境を織り込んでのサービス信頼性向上は、パッケージ屋としての経験が活かしやすい部分かもしれません。

医療機関の情報セキュリティ基準はだいぶ明確

医療機関といえばランサムウェアに狙われている印象がありますが、国から出ている情報セキュリティ関係のガイドラインはわりと明確です:

  1. 医療情報システムの安全管理に関するガイドライン 第5.2版(令和4年3月)
  2. 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン

明確なら実行も簡単というわけではもちろん無いのですが、ゴールや判断基準が明確であればベンダーとしてのお客様とのコミュニケーションはやりやすい部分があると思っています。

ここで面白いのが、この「3省2ガイドライン」と呼ばれる2つのガイドラインはそれぞれ「医療機関」と「医療情報システムを開発/運用する情報処理事業者」とを対象にしている点です。つまり3省2ガイドラインに準拠した医療を提供するには、医療機関とベンダーの双方が継続的に協力しないといけないということですね。 情報セキュリティ周りには取得して何が守られるんだっけみたいな認証とか違反が明らかになっても剥奪されない認定とかが跋扈している印象がどうしても拭えないのですが(個人の感想です)、このある種の緊張感あるガイドラインは結構好きです。

ちなみに医療機関向けセキュリティ教育支援ポータルサイトも整備されてきていて、国も然るべき手をきちんと考えて打っているのだなと思わされます。数年後は医療機関の情報セキュリティに対する印象も大きく変わっているかもしれませんし、微力ながら変えるための一翼を担えればと思います。

mhlw-training.saj.or.jp

採用が活発

組織は人、人は採用からということで採用にめっちゃ力を入れているわけですが、まさか入ってすぐここまで駆り出していただけるとはという驚きがありました。日常的な採用プロセスはもちろん、インタビュー記事だけでも2回も出していただいています:

実際JVMやバイトコードの酸いも甘いもじっくり10年超見てきた自分がSREやってますというのはサーバサイドKotlinを推す企業の採用戦略としては非常に正しいと思うので、今後も貢献できればとは思っております。実際やりたい・やるべき施策も大量にバックログに積んであって、当面は忙しそうだなという感じです。

あとは社内外の勉強会も活発で、自分が直接関わったものだけでも6回くらいやりましたね。会社ブログに情報が出ているのは以下です:

おかげさまで他社様とのコラボレーション企画も多く、こういうフットワークの軽さと顔の広さはすごくいいなと思っています。VPoEの弛まぬ尽力の賜ですね。自分自身も他者に声をかけられる・かけていただける開発者でありたいものです。

シニアだけ採用する != 教育不要

さすがにGitコマンドの使い方とかテストコードを書こうねみたいな意識付けとかは要らないんですが、シニアだから教育不要ということは全く無くて、むしろシニアだからこそ新たな学習機会を求めるのですよね。自分のバックグラウンドは他の社員と比べてやっぱり異色なので、ドメイン知識や技術を学びつつ自分からも還元できればと思っています。

とりあえずKotlin Fest 2022で話したようなDetektの話とか、結構突っ込んで研究してきたGradleの話とかは役立てていただけているように思います。特にGradleやGitHub Actionsはちょっとした工夫でぐんとビルド時間が短縮されるので、開発体験の向上に貢献できているかなと。15-20分かかっていたワークフローを12-15分くらいに短縮して、でも5分くらいにしたいよねっていう話をしているのが今です。頑張ります。

それはそれとして、才能ある新入社員と継続的に話して成長を支援することを続けてきた自覚はあるので、そのうち新卒採用もできると嬉しいです。新卒で入ってきてくださった方のほうが自分よりもめっちゃ優秀、みたいな体験があるとやはり緊張感出ますし、お客様の課題を解決するのとはまた違った達成感もありますし。

肩書に助けられてたんだなぁという話

前職では上司と駐在員という肩書があったので、新しく入ってきた”部下”との関係構築が比較的やりやすかったように思います。一方で新しい職場はフルフラットなのでこうしたバフやバイアスが存在せず、日頃から関係を構築しておかないというべきことも言いにくい(言えない空気はないんだけど「お前何様だよ?」って自分で思っちゃう)のだなという新鮮な発見がありました。自分が相手の”上司”であるという責任感にけっこうバフもらってたんですね。

6ヶ月あればさすがに言い方がわかってきて、相手が誰であろうと自分の弱さや専門性をどんどん出していこう感は出てきているのですが、「人間を信用しないで!」とか「KILL ALL HUMANS」とか叫んでるとさすがに自分でも「おっ、サイコパスか?」とは思いますね。

技術的ディスアドバンテージの埋め方

TerraformとGolang、GCPは入社してからのキャッチアップでした。GCPはQwiklabsがあるのでまだ楽でしたが、Terraform周りは自分がまだあまり読めないGolangで書かれていてけっこう難しく、大きめの失敗をいくつか経験しました。副業で入ってきていただいてる詳しい方に何度もサポートいただいて助かりました。

当たり前なんですが、詳しい方にどんどん聞く、わからないことをわからないと叫ぶことはとても大事だなと思います。Working Out Loud風の働き方は今後も継続していきたいです。

まとめ

土地勘がついてきてどういった貢献ができるのか・誰に聞けばわかるのかが見えてきた感じです。組織の規模や形が変わったことで自分の動き方も変える必要が出てきたところと、今までの強みが活かせるところとを理解して動いていきたいです。

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 よりは使いやすそう。