GitHub ActionsのDeployment jobがPendingのまま進まないときの確認

GitHub ActionsのDeployment jobがPendingのままなら、待っている理由をrun画面で確認します。environmentの承認待ち、wait timer、外部の保護ルール、concurrency、runner待ちは別の状態です。Pendingという語だけで、承認ボタンを押せば直るとは判断しません。

この記事はGitHub.comのenvironmentを参照するjobの診断です。実際の承認・デプロイ・保護設定変更・workflow再実行は実施していません。表示名や利用可能な保護機能は、契約とrepositoryの公開範囲、GitHub Enterprise Serverのバージョンなどで確認してください。

対象run・commit・environmentを固定する

run URL、job、event、refとcommit SHA、environment名、待機開始時刻を記録します。同じworkflowでも、別のrunや別environmentの承認通知を見ている場合があります。画面の待機理由とYAMLのenvironment指定を対応させます。

表は横にスクロールできます

表示・観察	最初に見る場所	混同しないこと
Review deploymentsの通知	対象environmentのreview	PRのcode review
timerによる待機	environmentのwait timer	runnerの処理遅延
protection ruleの結果待ち	対象ruleと外部system	job内のAPI認証
concurrency group待ち	同じgroupの先行run/job	environment承認
runner待ち	runs-on、runnerの利用状態	reviewerの不在

jobのstepがすでに始まって失敗している場合は、承認待ち診断だけでは解決しません。失敗stepのlogへ切り替えます。上流jobの結果やneedsが原因なら、先にそちらを確認します。

required reviewerの対象と自己承認制限を見る

GitHubのreview手順（新しいタブで開く）に従い、reviewが必要なrunではReview deploymentsから対象environmentを確認できます。承認は実際のdeploymentを進める操作なので、調査のために押さず、内容を確認するreviewerへ渡します。

environmentの公式reference（新しいタブで開く）では、required reviewersのうち一人の承認で進める仕組みを説明しています。全員の返答が必要だと推測せず、設定されたuser/teamと現在のreview状態を確認します。prevent self-reviewが有効なら、runを開始した本人はreviewerに含まれていても自己承認できません。

承認済みなのに動かない場合は、承認対象のenvironmentが同じか、他の保護条件が残っていないかを確認します。承認が通って初めてenvironment secretsへアクセスできる条件もあるため、承認前の待機をsecretの値の修正で直そうとしないようにします。

timer・branch制限・外部ruleを別々に読む

wait timerは、job開始前に設定時間を待たせる保護機能です。設定値と起点、経過時間を確認し、不要だと思って診断中に0へ変更しません。必要な時間が過ぎていないなら、その待機は期待した動作の可能性があります。

branch/tagの制限では、workflowの実際のrefが対象の規則に合うかを見ます。PRの表示branch名だけで判断せず、実行eventに応じたrefを確認します。外部のdeployment protection ruleなら、そのruleの判定、連携先の結果、対象deploymentとの対応を管理者へ確認します。外部ruleは現行資料でpreviewとして扱われるため、すべての環境にある前提にしません。

表は横にスクロールできます

未充足の条件	残す証拠	次の担当
reviewer待ち	environment・run・対象SHA	指定reviewer
timer	設定時間と経過	運用担当
ref制約	event・ref・対象rule	repository管理者
外部rule	rule名・判定状態・時刻	連携system管理者
確認権限がない	見えた状態と未確認項目	environment管理者

concurrencyとrunner待ちは別の経路で調べる

environmentの保護条件が満たされていても、同じconcurrency groupの先行処理やrunnerの割当を待っているなら、reviewerを増やしても解消しません。関連runの状態、評価されたgroup、対象jobのrunner条件を読みます。先行jobを無条件にcancelすると、途中まで行った外部更新が残る場合があります。

同じdeploymentを再実行してPendingを増やす前に、元runがまだ有効かを確認します。再実行で新しい入力やSHAへ変わるなら、以前の承認対象と同じだと扱いません。必要なreviewの判断を省かず、今回進めるrunを一つに絞ります。

承認判断に必要な情報をそろえる

reviewerには、対象commit、変更内容、検証結果、environment、想定する外部変更、戻し方を渡します。承認後も残る保護条件がある場合は、その状態も添えます。Start all waiting jobs等のbypassは通常の復旧手順にしません。保護ルールを外す行為には、組織の別の運用判断が必要です。

処理が進んだ後は、jobが開始したこととdeployment完了を分けて確認します。必要なstep、対象バージョン、サービス側の結果、失敗や部分成功がないかを記録します。Pending解消だけで公開先が正常になったとは判断しないようにします。

調査完了の記録は「どの条件が待たせていたか」「誰がどの根拠で進めたか」「どのrun・SHAがどこまで反映されたか」です。まだ待っている場合も、確認できた条件と次の担当が分かれば、原因不明の再実行を繰り返さずに引き継げます。