同じGitHub Actionsのrunで、build jobの成果物を次のjobへ渡したはずなのに「見つからない」。まず、download-artifactがartifactを選べないのか、ダウンロード後のファイルを後続stepが見つけられないのかを分けます。どちらも似た表示になり得ますが、直す設定は違います。
この記事は、同一workflow runのjob間で、生成・upload・download・利用先pathを対応させる手順です。別workflowや別runから取得する場合は、生成元runと認証範囲の確認が別に必要です。
目次
最初にエラーを出したstepを特定する
失敗jobの最終表示だけでなく、最初にエラーを出したstepと、その直前のdownload結果を開きます。downloadが完了していて、後続のテスト・コピー・配布処理がpath not foundを出しているなら、artifact選択ではなく展開先と利用pathの不一致を調べます。
表は横にスクロールできます
| 失敗地点 | 先に見ること |
|---|---|
| 生成step | 期待ファイルが作られたか |
| upload step | 対象path、artifact名、実行・Skippedの結果 |
| download step | 同じrunの名前・ID、対象Action版 |
| download後のstep | 展開先、相対path、利用するファイル名 |
artifact名と、内包するファイル名・ディレクトリ名は同じではありません。名前をweb-bundleと付けたからといって、展開後に必ずweb-bundleというフォルダーが作られるとは考えないでください。
jobの依存関係と実際のupload完了を見る
GitHubの公式artifact共有資料は、前のjobの成果物を必要とするjobをneedsで依存させる例を示しています。生成jobの完了前に利用側が探していないか、意図したjobへ依存しているかを確認します。GitHub：Store and share data with workflow artifacts（新しいタブで開く）
ただしneedsがあるだけで、uploadが実行された証明にはなりません。生成jobが成功していても、条件によりuploadだけSkipped、空の出力path、想定と違うartifact名、といった状況を確認します。
表は横にスクロールできます
| 生成側の確認 | 利用側と合わせるもの |
|---|---|
| run・commit・job | 同じ実行の成果物か |
| upload stepの結果 | 完了したartifactがあるか |
| artifact名またはID | 利用側が選ぶ対象と一致するか |
| 内包ファイルの一覧 | 後続処理が必要な内容があるか |
別jobで同じ相対pathを書いても、前jobで作ったファイルがそのまま存在する保証にはなりません。jobをまたぐデータの受渡しとしてupload／downloadを確認し、実行環境のファイル残存へ依存しない構成にします。GitHubのjob資料も、job間の依存関係を明示して実行順を制御する方法を案内しています。GitHub：Use jobs in a workflow（新しいタブで開く）
展開先と後続pathを一段ずつ合わせる
現行download-artifact READMEでは、一つのartifactを名前またはIDで取得すると、内容を指定pathへ直接展開する扱いです。すべてのartifactを取得する場合の名前別ディレクトリと混同しないでください。使用版での入力・出力と展開方法を確認します。GitHub：actions/download-artifact（新しいタブで開く）
次は、artifactの中にindex.htmlとassets/app.jsが入っていると仮定した配置例です。実runから取得した結果ではありません。
表は横にスクロールできます
| 項目 | 例 |
|---|---|
| artifact名 | web-bundle |
| 内包ファイル | index.html、assets/app.js |
| download先path | received |
| 確認するファイル | received/index.html、received/assets/app.js |
| そのまま想定しないpath | received/web-bundle/index.html |
後続stepのworking-directoryも合わせて見ます。相対pathはそのstepが動く位置に依存するため、downloadの入力値だけを直しても、利用側が別のディレクトリを基準にしていれば見つかりません。download-pathの出力や実際のファイル一覧を、秘密値を含めない範囲で利用します。
ファイル一覧を確認できたら、後続処理へ渡すrootを一つに決めます。エラーを消すためにrepository全体を配布対象へ広げたり、存在する別フォルダーを推測で指定したりしないでください。
「中の一部だけない」場合は別に調べる
artifact自体は取れたがdotfileだけがない場合、upload時の隠しファイル設定や対象pathを調べます。artifact全体が見つからない場合と同じ対処にはしません。また、過去runの成果物なら、保存期限・run削除・対象IDも確認します。
ActionのバージョンやGitHub Enterprise Serverの対応範囲も記録します。古いissueにあるworkflow例のバージョン、権限、公開・配布処理を、そのまま現行環境へ移植しないでください。受渡しの検証は、機密を含まない小さな成果物を使い、外部公開のない環境で行えます。
復旧確認は受渡しと内容を組にする
確認用のファイルに、非機密の識別子を入れておくと、別のrunや古い成果物を使っていないか比較できます。実際の業務データを診断用に公開する必要はありません。
表は横にスクロールできます
| 確認 | 合格条件 |
|---|---|
| 実行順 | 意図した生成jobの後に利用する |
| artifact選択 | 名前・ID・runが生成側と一致する |
| 展開先 | 指定rootに必要な相対pathがある |
| 版と内容 | 対象commit・識別子・必要ファイルが合う |
| 後続処理 | 同じrootを使い、不要ファイルを含めない |
完了時は「ダウンロード成功」だけでなく、後続stepがどのpathの何を使えたかを記録します。未解決なら、最初の失敗step、artifact名、upload対象、download先、working-directory、機密を除いたファイル構成をそろえて担当者へ渡してください。本記事は公式仕様に沿った診断手順で、実repositoryのworkflow実行や成果物の公開・配布を行った報告ではありません。