Kotlin・KSP・Compose Compiler を安全に更新する Renovate 設定術(developブランチ運用編)

Jetpack Compose Compiler が Kotlin に強く依存していた時代を経て、
今では少しずつ依存関係が緩やかになってきました。
それでも Kotlin・KSP・Compose Compiler の3つは依然として密接に関係しており、
バージョンのズレひとつでビルドが崩壊するリスクがあります。

この記事では、develop ブランチをメインに運用しつつ、
それらを安全かつ一貫性を保って更新するための Renovate 設定を紹介します。

 

🧩 Kotlin・KSP・Compose Compiler の三位一体更新

Compose Compiler は Kotlin コンパイラと深く結びついて動作するため、
Kotlin のメジャーアップデートが入ると、それに対応した Compose Compiler が必要になります。

さらに、KSP(Kotlin Symbol Processing)も Kotlin バージョンに追随するため、
この3つは基本的に「セットで更新する」のが鉄則です。


{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "baseBranches": ["develop"],
  "packageRules": [
    {
      "groupName": "Kotlin, KSP and Compose Compiler",
      "groupSlug": "kotlin",
      "matchPackagePrefixes": [
        "com.google.devtools.ksp",
        "org.jetbrains.compose.compiler"
      ],
      "matchPackagePatterns": [
        "org.jetbrains.kotlin.*"
      ]
    },
    {
      "description": "Do not automerge without CI",
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "automerge": false
    }
  ]
}

 

⚙️ 設定の意図を読み解く

この設定は、単に自動更新を行うだけでなく、
Kotlin 界隈の依存を安全に、かつチームの開発フローに合わせて管理することを意識しています。


baseBranches: ["develop"]

Renovate のデフォルトは main や master に対して PR を作りますが、
実際の開発フローでは「開発用ブランチ(develop)」に更新を入れたいケースが多いですよね。

"baseBranches": ["develop"] を指定しておくことで、
更新 PR が常に develop ブランチに向けて作成されるようになります。

本番リリース前にテストや検証を挟める安全設計です。

 

🔗 groupName: 三つ巴のアップデートを1つにまとめる

groupName は、関連する依存をひとまとめにするためのグループ名。
ここでは "Kotlin, KSP and Compose Compiler" としており、
3つのパッケージを同時に1つの PR にまとめてくれます。


"matchPackagePrefixes": [
  "com.google.devtools.ksp",
  "org.jetbrains.compose.compiler"
],
"matchPackagePatterns": [
  "org.jetbrains.kotlin.*"
]

この指定で次のような依存が同時更新対象になります:


- Kotlin (org.jetbrains.kotlin)

- KSP (com.google.devtools.ksp)

- Compose Compiler (org.jetbrains.compose.compiler)

以前は androidx.compose.compiler でしたが、
現在の Compose Multiplatform では org.jetbrains.compose.compiler に移行しているため、この設定がより正確です。

 

🚫 automerge: false の哲学

Renovate には更新を自動マージする機能がありますが、
Kotlin 系の更新はそれに向きません。

理由は単純で、CI でのビルド確認が欠かせないからです。


{
  "description": "Do not automerge without CI",
  "matchUpdateTypes": ["minor", "patch", "digest"],
  "automerge": false
}

「CI による確認を通らない限り、自動マージさせない」というルールです。

特に Kotlin の minor アップデートでは内部 API が変わることもあり、
Compose Compiler や KSP が対応していない可能性があります。

PR を作成したあと CI を通し、問題なければ手動でマージする。

これが最も安全な流れです。

 

🧭 運用のヒントとまとめ

この設定は、いわば「Kotlin エコシステム用 Renovate セーフティモード」。

自動化の恩恵を受けつつも、壊れやすい依存を慎重に扱うための現実的な妥協点です。

項目 意図
baseBranches 更新PRをdevelop向けにして安全確認を確保
groupName Kotlin / KSP / Compose Compiler を同時に更新
automerge: false CI確認なしでの自動マージを防止
matchPackagePrefixes / matchPackagePatterns 最新の Compose 構成(Compose Multiplatform 等)に対応

 

🪶 まとめ:安全第一の Renovate 運用へ

Renovate は「ただの自動更新ボット」ではなく、
チームのアップデート戦略をコード化できるツールです。

Kotlin、KSP、Compose Compiler のような密接な関係を持つ依存こそ、
グルーピングとマージ制御で慎重に扱うべき対象。

develop ベースで CI を通すこの設定は、
自動化と安全性のバランスを取る最適解のひとつと言えます。

👉 Renovate Docs


Gradle ビルドキャッシュや KSP キャッシュを消すとき Gradle デーモン止めないと意味がない件

Android 開発をしていると、Git 操作後や依存関係を変更したあとに KSP(Kotlin Symbol Processing)やビルドキャッシュの問題 に遭遇することがあります。


java.lang.IllegalStateException: Storage for [C:\...\symbolLookups\id-to-file.tab] is already registered

この記事では、Gradle デーモンとキャッシュの関係を整理し、「キャッシュを消したのにビルドが直らない」問題 を回避する方法を解説します。

 

🤔 Gradle デーモンとは何か

Gradle はビルドの高速化のために デーモン と呼ばれるバックグラウンドプロセスを使います。

常駐プロセスとして、次回のビルドでキャッシュを再利用

複数プロジェクトやターミナルで同時に動作可能

Android Studio 再起動だけでは停止しない場合がある

デーモン状態の確認方法


./gradlew --status


No Gradle daemons are running

→ デーモン未起動


PID STATUS INFO
3494 IDLE 8.11.1

→ デーモン起動済み、待機中


PID STATUS INFO
3494 BUSY 8.11.1

デーモン停止は以下で可能:


./gradlew --stop

 

🤔 キャッシュを消しても直らない理由

KSP や Gradle のキャッシュを削除しただけでは、既に動作中のデーモンが古いキャッシュ情報を保持している場合があります。

典型的なケース


1. git rebase でコミットを整理

2. KSP が参照する Room の型情報や生成コードが変更

3. Gradle デーモンが古いキャッシュを保持 → ビルド失敗

つまり、キャッシュを消しても、デーモンが古い情報を持っている限り意味がありません。

 

🤔 解決手順まとめ

① Gradle デーモンを止める


./gradlew --stop

すべての Gradle デーモンを終了

次回ビルド時に新しいデーモンが起動

② KSP キャッシュを削除する


rm -rf .ksp/ */build/kspCaches */build/generated/ksp/

KSP が持つ生成キャッシュを完全に削除

再ビルド時に最新のコードから生成される

③ Android Studio のキャッシュをクリア


File → Invalidate Caches / Restart → Invalidate and Restart

IDE 側のキャッシュもクリア

デーモン再起動時に正しい情報を読み込む

④ KSP のインクリメンタルコンパイルを無効化(必要に応じて)

gradle.properties に追加:


ksp.incremental=false

キャッシュ競合によるエラー(例:java.lang.IllegalStateException: Storage for [C:\...\symbolLookups\id-to-file.tab] is already registered)を回避

 

🤔 Git Rebase 後の KSP ビルドフロー


Git Rebase
    ↓
ソースコード変更
    ↓
KSP キャッシュ古いまま
    ↓ (Gradle デーモン生きている場合)
ビルド失敗 → Storage already registered など
    ↓
./gradlew --stop でデーモン停止
    ↓
KSP キャッシュ削除
    ↓
再ビルド
    ↓
成功

 

🤔 まとめ

Gradle デーモンは Android Studio 再起動だけでは必ずしも止まらない

KSP やビルドキャッシュを消すときは必ずデーモンを止める

典型的な手順:


./gradlew --stop

rm -rf .ksp/ */build/kspCaches */build/generated/ksp/

Android Studio キャッシュクリア

ビルド再実行

これで Git 操作後や依存関係変更後のビルド失敗を防げる

Gradle デーモンの挙動を理解しておくと、「キャッシュ消したのに直らない」問題 に悩まされずに済みます。

ビルド高速化の恩恵を受けつつ、必要なときにはデーモンを適切に制御しましょう。

android - java.lang.IllegalStateException: Storage for [C:\...\symbolLookups\id-to-file.tab] is already registered - Stack Overflow


初心者向け Git コマンドと領域の移動をシーケンス図で書いてみた

Git 公式リンクから確認しておきたい初心者機能を抽出して、操作の流れに合わせて状態の変化、確認方法をシーケンス図でまとめます。

👉 Git - Reference
👉 とほほのGit入門 - とほほのWWW入門

👉 Git の初心者がつまづく領域の名称
👉 GitHub + SSH で複数アカウント切替え