ビルド フォルダーが適切にクリーンアップされない

要約

ランナーはステップの最後に、ビルド フォルダーのクリーンアップを試みます。これはベスト エフォート型のクリーンアップであり、場合によってはランナーがビルド フォルダーをクリーンアップできない可能性があります。次は、ランナーがビルド フォルダーをクリーンアップするのを妨げる 2 つの最も一般的なケースです。

• ステップ スクリプトが、ランナーが削除する権限を持たないファイル (すべてのユーザーに対して FullControl を Deny に設定するなど) を作成する場合。

• The step script is creating orphaned processes that a runner is not able to stop, and some of the files in the build are locked by those orphaned processes. For example, a hosted machine had Gradle daemon (which is not suggested by Gradle), and is set to use daemon for all Gradle builds by: org.gradle.daemon=true. In this case, the processes created by Gradle builds will attach to the existing daemon process, and the runner would not able to stop them at the end of the step.

上記のいずれの場合も、ランナーがビルド フォルダーをクリーンアップできなくなります。さらに、ランナー ログを確認してホスト マシンにあるビルド フォルダーを手動でクリーンアップするように指示するエラーが発生して、ステップが失敗します。このランナーで実行するようにスケジュールされているその後のステップもビルド フォルダーが正しくクリーンアップされていないため、エラーが発生します。

ソリューション

You need to contact the admin who has access to the runner and check the runner logs to find out which files are preventing the runner from cleaning up the build folder.

ランナーが削除できない権限を持つファイルの場合は、管理者がそれらのファイルの権限を修正してビルド フォルダーを削除し、ランナーを再起動する必要があります。

孤立したプロセスによってロックされているファイルの場合は、管理者がファイルをロックしたプロセスを見つけてそのプロセスを強制終了する必要があります。次に、ビルド フォルダーを削除してランナーを再起動します。

上記のいずれの解決策においても、ステップ スクリプトとホスト マシンの現在の設定を再確認して、ステップを次回実行する際にそのステップがビルド フォルダーをロックしないようにする必要があります。または、ホスト マシンで手動クリーンアップを再実行する必要があります。Gradle デーモンの場合は、Gradle ビルドに --no-daemon オプションを追加すると、子プロセスが Gradle デーモンに結びつくことを防げます。