Azure Pipelines の Ubuntu 26.04 で「Access to the path '/home/vsts' is denied」
Microsoft がホストする 24.04 までの Ubuntu のエージェントは、ユーザー vsts として動き、ジョブのフォルダーは /home/vsts/work/1 です。Ubuntu 26.04 のイメージでは runner として動き、ジョブのフォルダーは /home/runner/work/1 で、/home/vsts はありません（runner-images #15028・未解決）。/home の持ち主は root なので、/home/vsts の下に何かを作ったり書いたりするステップは拒まれます。Microsoft の定義済み変数のページは、今も例として /home/vsts/work/1 と /home/vsts/work/_temp を挙げていて、こうしたパスの多くはそこから来ています。
パイプラインを変えていないのに始まる理由
Microsoft のホストされたエージェントのページ（10月6日に更新）は、今も ubuntu-latest を 24.04 としていて、YAML のパイプラインがイメージを書いていなければ、そのイメージが使われます。けれども、ubuntu-latest を 26.04 に移す作業（2026年10月19日から11月19日にかけて）は、当たる対象に Azure DevOps を挙げていて（runner-images #14748）、パイプラインはもう 26.04 に当たっています。vmImage: 'ubuntu-latest' のパイプラインは10月26日に 26.04 のイメージ 20261012.163.1 で動き、vmImage を書いていないパイプラインは11月2日に 20261025.179.1 で runner として動きました。その前に通った回は 24.04 で vsts でした。移行が終わるまでは、再実行が 24.04 に当たって通ることがあります。
どう見えるか
Cache@2 のタスクで、path が /home/vsts の下にあると、キャッシュが見つかったあとにこうなります（runner-images #14748 の11月2日のコメント）：
There is a cache hit: ... ##[error]Access to the path '/home/vsts' is denied.
ビルド検証のパイプラインで、ソースのフォルダーを自分で作るスクリプト（runner-images #15105）：
fatal: cannot mkdir /home/vsts/work/1/s: Permission denied
タスクの入力に決まったフォルダーを書いた例：HawkScan の installPath: '/home/vsts/custom' でリリースのビルドが止まりました（javaspringvulny #111）。リポジトリを /home/vsts で検索します。YAML・スクリプト・Docker のボリュームのマウント・設定ファイルです。
直し方：パスを変数から組み立てる
- ソース：
$(Build.SourcesDirectory)、スクリプトでは$BUILD_SOURCESDIRECTORY。git initの例への runner-images のメンテナーの答えはgit init "$env:BUILD_SOURCESDIRECTORY"です。 - ジョブのフォルダー：
$(Pipeline.Workspace)、または$PIPELINE_WORKSPACE。 - ツールやダウンロードの作業用：
$(Agent.TempDirectory)。ジョブごとに空になります。HawkScan の直しは$(Agent.TempDirectory)/hawk-customを使っています。 - ユーザーのホーム：bash では
$HOME、PowerShell では$env:HOME。タスクの入力からは読めないので、先にスクリプトのステップで変数にします：
steps:
- bash: echo "##vso[task.setvariable variable=userHome]$HOME"
displayName: Find the agent user's home
- task: Cache@2
inputs:
key: 'deps | "$(Agent.OS)" | Dependencies.toml'
path: $(userHome)/.ballerina/repositories
Microsoft のキャッシュの例は、そもそもホームのフォルダーを使いません。ツールのキャッシュを $(Pipeline.Workspace) に向け（たとえば npm_config_cache: $(Pipeline.Workspace)/.npm や GRADLE_USER_HOME: $(Pipeline.Workspace)/.gradle）、そのパスをキャッシュするので、どちらのイメージでも同じように動きます。キャッシュしたファイルが絶対パスを持っている（ツールによってはホームを書き込みます）なら、一度キーを変えて、26.04 で新しいキャッシュを作らせます。
当面は古いイメージのままにする
pool: vmImage: 'ubuntu-24.04'
古いレイアウトのままにするために、メンテナーが勧めている方法です。イメージを書いておくと、回ごとに 24.04 と 26.04 が入れ替わることもなくなります。ただし時間かせぎなので、26.04 に移る前にパスを変数に直します。
見分け方
- ログの Initialize job のステップに、イメージとその版が出ます。たとえば
Image: ubuntu-26.04。 whoamiがrunnerを、echo $HOMEが/home/runnerを表示します。- セルフホストのエージェントは関係ありません。ユーザーはエージェントを入れたときのままです。
26.04 のもう1つの変更：conda
26.04 のイメージには Miniconda が無く、CONDA が空です。そのため、Microsoft の Anaconda の手順どおりに $CONDA/bin を PATH に足すパイプラインは、「conda: command not found」と終了コード 127 で落ちます：ステップで Miniforge を入れるか、vmImage: ubuntu-24.04 のままにする。
IntelliJ IDEA と Rider でのビルド検証
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。プルリクエストを、ブランチ ポリシーを平易な文にして IDE のツールウィンドウに並べるので、移行のあいだに落ち始めたビルドのポリシーは、プルリクエストの横に「満たしていない」と出ます。Pro では、失敗したビルドや期限切れのビルドに再実行のリンクが出て、もう一度キューに入れられます。レビューの受信箱とブランチ ポリシーは無料、投票・コメント・完了・ビルドポリシーの再実行・プルリクの作成は Pro（月 US$1・30日間の無料試用つき）です。画面は日本語です。
Azure DevOps は Microsoft Corporation の商標、Ubuntu は Canonical Ltd. の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・Canonical・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：ビルド検証：期限切れのビルドと、プルリクのビルドが動かない理由 · 「fatal: could not read Username for 'https://dev.azure.com'」 · GitHub Actions での同じ移行 · English