actions/checkoutのpersist-credentialsをfalseにすべき理由
対象読者
- actions/checkoutを使用したGitHub Actionsワークフロー開発で、何故かgitの認証エラーが出た人
- これから使いまわせるComposite Actionを開発予定の人
モチベーション
- 業務でactions/checkout + 既存Composite Actionの組み合わせでgitの認証エラーが出て時間を溶かした。
- 同じ轍を踏みたくないのと、世の中のComposite Actionを開発する方に意識して実装してほしくて書いている。
遭遇した事象と詳細、今後すべきこと
何が起こったか
開発中のワークフローからactions/checkoutをパラメータ無しで実行した後に、共用Composite Actionを呼び出したところ、以下のエラーが発生した。
remote: Duplicate header: "Authorization"
Error: fatal: unable to access '実際のリポジトリURL': The requested URL returned error: 400
The process '/usr/bin/git' failed with exit code 128
エラーメッセージを見ても「Authorization headerが重複？何言っているんだ？」と、原因がわからなかった。
最初は「いや、ワークフロー内では1回しかcheckoutしとらんやろ。」と。
Composite Actionの中を見た後は「checkoutを複数回実行しているからAuthorization headerが重複している？いやいや、普通にgit操作する時はそうはならんやろ。」と。
それぞれ原因まで考えが直結せず、ハマってしまった。
何が原因だったか
actions/checkoutのpersist-credentialsがtrueな状態でactions/checkoutを複数回呼び出した関係で、既に認証情報が保存されている状態で新しい認証情報を追加で使おうとしてコケたっぽい。
see: 公式情報
なお、actions/checkoutのpersist-credentialsは、未指定だとtrueが設定される。
今回はワークフロー側のステップ、そのステップから呼び出したComposite Action内両方とも未設定だった。
挙動を見るに、ジョブ単位（not ステップ単位、ワークフロー単位、アクション単位）で認証情報が保存され使いまわされる模様。
今後、どうしたらよいか
actions/checkoutのpersist-credentialsは必ずfalseに設定する。
- uses: actions/checkout@v6.0.1
with:
persist-credentials: false
そうすることで、今回ハマったようなエラーは発生しなくなる。
そもそも、認証情報を保存して使いまわさなくても手間が変わらない・処理速度が大して変わらないなら、セキュリティ上、保存しないに越したことはないと思う。（悪用とか怖いし。）
参考情報に記載させていただいたZenn記事の内容を参考に、ruleや自動修正ツールで自動でfalseにしてしまうのが一番楽そう。
（これが一番楽だと思います。）
注意しないと発生するホラーケース
persist-credentialsをtrueに設定した時に発生しそうなホラーケースについて書いていく。
- 同一ジョブ内の後続ステップで3rd party製actionを呼び出した時に、認証情報を使いまわされて悪いことをされる。
- 使いまわすことができるComposite Actionを開発したつもりが、組み合わせによっては使えなくなる。
- これは、尖った作りにしていない限りではComposite Action側で明示的にpersist-credentialsをfalseに設定して回れば良いだけだが。
- 設定を変更するのは一瞬でも、影響範囲を考慮した念のためのテストが面倒くさい。
Discussion