生成側workflowのArtifacts欄には成果物があるのに、利用側workflowでは見つからない。最初に確かめたいのは、利用側がどのrepositoryとrunを検索しているかです。同じartifact名を指定しても、別workflowの最新成果物が自動的に選ばれるとは限りません。
この記事では、buildと後続処理を別workflowへ分けた保守担当者が、生成元run・artifact識別子・取得権限を照合する順番を扱います。同一runの別jobへ渡す場合の実行順、保存期限切れ、dotfileだけの欠落は、切り分け後の別確認です。
目次
同じrun内の受渡しか、別runの取得かを決める
GitHubの公式資料は、別workflowまたは別workflow runからartifactを取得する場合、tokenとrunの識別子を指定するよう案内しています。名前だけで探す前に、生成側と利用側それぞれのrun URLを開き、同じrunなのかを確認します。GitHub：Store and share data with workflow artifacts（新しいタブで開く）
表は横にスクロールできます
| 生成側と利用側の関係 | 最初に見る箇所 | 取り違えやすいもの |
|---|---|---|
| 同じworkflow runの別job | upload完了とjobの依存関係 | まだ生成されていないartifact |
| 別workflow・別run | 生成元repositoryとrun ID | 利用側自身のrun ID |
| 再実行や複数候補がある | commit、作成時刻、artifact ID | 同名の古い成果物 |
同一runの別jobなら、生成jobが成功してから利用jobが開始する設計を確認します。一方、別runの問題をneedsの追加だけで直そうとしても、取得元runの指定は決まりません。まずケースを一つに絞ってください。
artifact名、ID、ファイル名を分けて記録する
artifactの名前は、中に入っているファイル名と同じ概念ではありません。さらに、workflow runのIDとartifactのIDも別です。診断票へ「ID」とだけ書かず、何を識別しているかを列名にします。
次は架空の照合例です。数値や名前は実在runの取得結果ではありません。
表は横にスクロールできます
| 項目 | 生成側で控える例 | 利用側で照合するもの |
|---|---|---|
| repository | example/build-repo | artifactを読む対象repository |
| workflow run ID | 42001 | 利用側自身のIDを入れていないか |
| commit SHA | 対象変更のSHA | 使いたい版と一致するか |
| artifact name | web-bundle | ファイル名や別runの同名物と混同しない |
| artifact ID | 73001 | その生成元runに属するか |
| 内容の相対path | public/index.html | 展開後に必要ファイルが存在するか |
公開してよい範囲の識別情報だけを残し、token値、署名付きdownload URL、credentialを票へ貼りません。run IDが合っていても、生成側のuploadがSkippedだったり、別名で保存されたりしていれば、期待するartifactはありません。生成側run summaryとuploadログを先に確かめます。
download-artifactの取得範囲を確認する
現行の公式READMEでは、github-tokenを指定しない場合は現在のrepository・現在のworkflow runから取得する動作を説明しています。別runや別repositoryを読む場合は、対象を読めるtokenとrepository、run-id等を組み合わせます。名前だけを一致させても取得範囲が切り替わるわけではありません。GitHub：actions/download-artifact（新しいタブで開く）
表は横にスクロールできます
| input | 確認する役割 | 典型的な取り違え |
|---|---|---|
| name | artifact名で対象を選ぶ | 展開後ファイル名を入れる |
| artifact-ids | artifactのIDで対象を選ぶ | workflow run IDを入れる |
| repository | 生成元owner/repository | 利用側repositoryのままにする |
| run-id | artifactを生成したrun | 現在の実行IDをそのまま使う |
| github-token | 対象を読むAPI認証 | 対象repositoryへ届かないtokenを使う |
使用中のAction バージョンのREADMEを確認し、利用できるinputと組合せに合わせます。現行READMEではnameとartifact-idsを同時に指定しない扱いです。GitHub Enterprise Serverでは対応バージョンも別に確認が必要なため、GitHub.com向けの現行majorをそのまま移植しないでください。
本記事はtokenを新規発行する手順ではありません。既存の認証経路で読める対象を確認し、足りない場合は権限者へ必要なrepositoryと操作を限定して相談します。取得元を誤ったまま広いtokenへ交換しても、正しい成果物を選んだ証明にはなりません。
権限不足と期限切れを分ける
GitHub REST APIのartifact取得関連endpointは、認証方式に応じたActionsのread permissionを案内しています。private repositoryではrepositoryへのアクセス範囲も合わせて確認します。利用側のtokenを指定できたことと、生成側を読む権限があることは同じではありません。GitHub：REST API endpoints for GitHub Actions artifacts（新しいタブで開く）
記録するのは、対象repository、run ID、artifact名またはID、HTTPステータス、エラー本文の機密を除いた部分です。認証エラーをすべて期限切れと扱ったり、404だけでartifact削除と断定したりしません。閲覧権限、指定先、生成結果、実際の保持状態を順に確認します。
対象が生成側でも見つからない場合は、uploadの実行有無、保存期限、run削除を調べます。生成側にはあり利用側だけ失敗するなら、先にrunの選択と認証範囲へ戻ります。全artifactを無差別に取得して名前を探す方法より、対象runの候補を絞った方が誤使用を避けられます。
取得できても、そのまま実行してよいとは限らない
workflow_run等で外部PR由来のartifactを受け取る場合、取得先がGitHubであることだけで内容を信頼しません。artifactに実行ファイル、script、設定が含まれ、それを権限のある後続workflowで実行すると、生成元の未信頼コードがその権限へ届く可能性があります。GitHub：Secure use reference（新しいタブで開く）
生成元イベント、repository、branch、commit、実行結果、内容の利用目的を確認します。例えばテスト結果のデータを読む処理と、そのartifact内のscriptを実行する処理は別に評価します。ファイル数やhashが合うことも、生成元コードの信頼性を保証するものではありません。
「ダウンロードが成功した」と「公開・本番処理に使ってよい」を分け、対象版の取り違えや未信頼内容の実行がないかを確認してから後続処理へ渡してください。
確認結果を一件の対応表にまとめる
復旧確認には、機密を含まない小さなテスト成果物と、許可された環境を使います。同名で異なるrunの成果物がある条件も想定し、取得した内容が指定した生成元と一致するかを見ます。
表は横にスクロールできます
| 確認 | 合格とする条件 | 未確認なら残すこと |
|---|---|---|
| 生成元の選択 | repository・run・commitが目的と一致 | 選択条件と候補run |
| artifactの選択 | 名前またはIDが生成側と一致 | upload有無・別名・保持状態 |
| APIアクセス | 必要なread範囲で取得できる | 認証方式・対象・エラー |
| 展開後の内容 | 必要pathと対象版が一致 | ファイル差分・欠落 |
| 後続利用 | 内容の信頼境界を確認済み | 実行しない範囲と担当者 |
完了時は「run 42001のartifact 73001を指定した」といった選択根拠と、実際の内容確認を組にします。名前が同じという理由だけで最新・正しい版と報告しないでください。ここで示した表は診断用の架空例であり、GitHub APIへの接続やworkflowを実行して検証した結果ではありません。