GitHub Actions:「Artifact not found for name」
actions/download-artifact が名前でアーティファクトを探し、そのワークフローの実行にはその名前のものがありませんでした。失敗するのはダウンロードのステップですが、原因はほとんどそれより前、アップロードするはずだったジョブか、名前にあります。
見え方
Error: Unable to download artifact(s): Artifact not found for name: build
Please ensure that your artifact is not expired and the artifact was uploaded using a compatible version of toolkit/upload-artifact.
For more information, visit the GitHub Artifacts FAQ: https://github.com/actions/toolkit/blob/main/packages/artifact/docs/faq.md
2行目と3行目は、原因が何でも同じです。github-token を渡さないと、このステップはいまの実行の中しか探しません。アクションの README にも、既定の権限ではいまのワークフローの実行の中のアーティファクトしかダウンロードできない、とあります。
1. アップロードがファイルを見つけられず、警告だけで済ませた
actions/upload-artifact の既定は if-no-files-found: warn です。パスに当たるファイルが無いと、「No files were found with the provided path」と出して成功し、アーティファクトを作りません。
- kroxylicious では、スクリプトがリリースノートを書かなくなり、ステージングのワークフローは成功と報告し、昇格のワークフローが
Artifact not found for name: RELEASE_NOTESで失敗しました(kroxylicious #5060)。 - pyvista では、ドキュメントの設定を変えたあとノートブックが書かれなくなり、アップロードは空のアーティファクトを飛ばし、main のドキュメントのビルドが毎回そのダウンロードで失敗しました(pyvista #9533)。
アップロードするはずだったジョブのアップロードのステップを開いて、この警告を探します。ほかのジョブが使うアーティファクトはエラーにしておくと、ファイルが無くなったところで実行が失敗します:
- uses: actions/upload-artifact@v7
with:
name: release-notes
path: dist/release-notes.md
if-no-files-found: error
2. アップロードするジョブが、まだ走っていない・終わっていない
- GitHub のドキュメントには、前のジョブのアーティファクトを使うジョブはそのジョブが成功して終わるのを待つ必要がある、とあります。
needsでつながっていないジョブは同時に始まります。lean-workers-union では、デプロイのジョブとサイトを作るジョブがどちらもテストのジョブだけを needs にしていたので、デプロイが先にダウンロードに着くことがあり、main の実行はどちらが先に着くかで成功したり失敗したりしていました(lean-workers-union #7)。 - needs にしたジョブが失敗するかスキップされると、そのジョブもスキップされます。ただし
if:が走らせる場合は別で、always()や!cancelled()だと走って、ダウンロードで失敗します。butler では、パスのフィルターで Windows のビルドがスキップされたとき、エンドツーエンドのジョブがそれでも走り、Artifact not found for name: windows-e2eで失敗しました(butler #1037)。
アップロードするジョブを needs に入れます。失敗のあとでも走らせたいジョブなら、そのジョブの結果も確かめます:
deploy:
needs: [test, build-site]
if: ${{ !cancelled() && needs.build-site.result == 'success' }}
3. 失敗したジョブの再実行と、名前に入れた実行の回数
「Re-run failed jobs」(gh run rerun --failed)は、失敗したジョブだけをもう一度走らせます。成功したジョブは走らず、結果もアーティファクトも前の回のままです。github.run_attempt は、ドキュメントによると最初の回が1で、再実行のたびに1つ増えます。なので、これを使った名前は、この回ではどのジョブもアップロードしていないアーティファクトを探すことになります:
- 1回目が
nddev-source-39616558599-1-releaseをアップロードし、再実行のデプロイはnddev-source-39616558599-2-releaseを探しました(std-0004-ci-cd-workflows #111)。 - afactory #562(
validation-plan-2)と moskophoros #172(plan-4。実行にあったのはplan-1だけ)も同じです。
ジョブからジョブへ渡すアーティファクトの名前には run_attempt を入れないようにします。再実行は前の回のアーティファクトをダウンロードし、アップロードするジョブがもう一度走って同じ名前でアップロードすれば、いちばん新しいものを取ります(toolkit のソースに「More than one artifact found for a single name, returning newest」とあります)。ファイルがこの回のものでないと困るなら、すべてのジョブを再実行します。
4. アーティファクトが別のワークフローの実行にある
CI が作ったものをダウンロードするリリースのワークフローは、どこにあるかを伝える必要があります。GitHub のドキュメントには、別のワークフローや実行からダウンロードするにはトークンと実行の ID を渡す、とあります。
on:
workflow_run:
workflows: [CI]
types: [completed]
jobs:
release:
runs-on: ubuntu-latest
permissions:
actions: read
steps:
- uses: actions/download-artifact@v8
with:
name: app-apk
github-token: ${{ github.token }}
run-id: ${{ github.event.workflow_run.id }}
別のリポジトリなら、repository: owner/name と、そのリポジトリの Actions を読めるトークンを足します。名前はそれでも完全に一致する必要があります。tucaVR では、CI が VR-Player-APK-<ブランチ>-<実行の ID> でアップロードし、リリースのワークフローは一度も作られていない VR-Player-APK-main を探していました(tucaVR #79)。
5. アーティファクトの名前が違う
- upload-artifact v7.0.0(2026年2月)で入った
archive: falseは、ファイル1つを圧縮せずにアップロードします。リリースノートによると、このときnameは無視され、アーティファクトの名前はアップロードしたファイルの名前になります。name: my_files.tarのように、ファイルの名前でダウンロードします。 - マトリックスのジョブは
binary-${{ matrix.os }}のように別々の名前にする必要があるので、ただのname: binaryでは見つかりません。pattern: binary-*とmerge-multiple: trueを使います。パターンに何も当たらないときは何もダウンロードせず失敗もしないので、あとでファイルを確かめます。
6. 期限が切れた
アーティファクトは保存期間が過ぎると消えます。既定は90日で、retention-days や、リポジトリ・組織の短い設定があればそれより短くなります。DiluxOne のワークフローでは、1日だけ残すアーティファクトが、29時間後に失敗したジョブを再実行したときには消えていました(DiluxOne .github #56)。再実行は30日までできるので、再実行で使うアーティファクトは、再実行するかもしれない期間より長く残します。
見分け方
- アップロードのステップが失敗している:「Artifact storage quota has been hit」や、マトリックスのジョブが同じ名前でアップロードしたことによる衝突。ダウンロードの失敗は2つ目の失敗にすぎません。
- GitHub Enterprise Server では、v4 以降は「not currently supported on GHES」で止まります。README は、そこでは v3 を使うように書いています。
- 同じジョブでアップロードした直後:2026年10月の2件の報告では、ダウンロードが失敗した少しあとにアーティファクトが一覧に出ていました(audio-pipeline #779・loop-protocol #2969)。どちらも原因はわかっていません。
- キャッシュはアーティファクトとは別です:「Cache not found for input keys」は
actions/cacheです。
失敗したジョブを IntelliJ IDEA から見るなら
Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE(2024.1 以降)のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べ、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro(月 US$1.50・30日の無料試用つき)です。
GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに:「No files were found with the provided path」 · 「Artifact storage quota has been hit」 · 1か月より前の実行の再実行 · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English