AIにはできないであろう、アクロバティックな回避をしたというネタ記事です。

注意点

相当昔に対応したので今はもう治っているかもしれないし、ほかの回避方法があるかもしれない。

背景

Gradleのmulti-project環境にSpotless（Java）を導入したところ、以下のような問題に遭遇しました。

Caused by: org.gradle.api.InvalidUserDataException: Cannot add a configuration with name 'spotless-XXXX' as a configuration with that name already exists.

issueはcloseされているが、問題が解消しなかった。
https://github.com/diffplug/spotless/issues/372

失敗例（やってみたけど安定しなかった）

ルート build.gradle にSpotlessを一括定義
各 subproject へSpotless設定を分散定義

回避策

CI限定の「単一プロジェクト化」＋フォーマッタ専用ビルドCI上でのみ、multi-projectの定義を外して「単一プロジェクトとして扱う」構成に切り替え、Spotless専用の build.gradle を適用して整形した。

メリット: フォーマットの再現性・安定性が高い。構成の影響をほぼ受けない
デメリット: 整形時に本来のモジュール構成と乖離するため、CI整形ステップは独立運用が必要

まとめると、「multi-project構成で動かないならシングルプロジェクトとして扱えばいいじゃないか」という回避方法です。

実際のCI

準備スクリプトプロジェクト構成例に合わせて、CIジョブで以下の準備を行います。
POSIXシェル版:

# settings.gradleから rootProject.name = '...' 以外の行を削除し、単一プロジェクト化
sed -i '/^rootProject.name =/!d' settings.gradle
# build.gradleをシングルプロジェクトで動くSpotlessを適用したbuild-logic/format-ci.gradle で上書き
cp build-logic/format-ci.gradle build.gradle
# java-style.xml をルートにコピー（Java整形用スタイル定義）
cp build-logic/java-style.xml .

その後、Spotlessを実行します。

gradlew --no-daemon spotlessCheck
# もしくは整形まで実施
gradlew --no-daemon spotlessApply

参考リンク