🐛
GitHub Actions の paths 条件による予期せぬ挙動を発見
こんにちは、ThaddeusJiang です。今回は GitHub Actions の paths 条件を使った際に発生する、思わぬ挙動についてご紹介します。
経緯
リポジトリで CI/CD を構築するために GitHub Actions を導入しました。設定したワークフローには、特定のパスでのみ test チェックを実行するようにしていました。
観察した現象
最初のコミットでは、PR のステータスは 1 failing, 1 successful checks となり、test チェックが失敗していることが正しく表示されていました。
その後、test エラーを修正しないまま、paths の対象外のファイルだけを更新してコミットを追加すると、なんと PR のチェックが 1 successful check となり、エラーが解消されたかのように見えてしまいました。
さらに、Pull Request 一覧画面でも ✅（成功）のアイコンが表示されます。
原因の推測
GitHub Actions の paths オプションを使っている場合、対象外のファイルのみが変更されたコミットでは、該当ワークフロー自体がスキップされます。そのため、前回のチェック結果が上書きされず、最新のコミットでは「失敗」したチェックが存在しない状態となり、PR 全体としては「成功」とみなされるようです。
まとめ
-
paths条件付きの GitHub Actions では、対象外ファイルだけのコミットでワークフローがスキップされる - その結果、以前の失敗チェックが無効となり、PR 全体が「成功」扱いになる
- CI の品質やレビューの信頼性を保つため、
paths条件の利用には注意が必要
同じような構成で GitHub Actions を運用している方は、一度自分のリポジトリでも挙動を確認してみてください。
再現する現場
Discussion
Privateになってるからか再現する現場のリポジトリが見えてないみたい。）
仕様どおりなので内容についてはアレだけど、しいて言えばCIでテストを回すワークフローを実行する条件（今回で言えばpaths）で設定するのは正直あんまりよくない。
そもそもテストをスキップしてマージしていいわけないので、テストはPRの更新都度確実に行うべき(on.push で常に回す)だし、どうしてもテストを実行したくないとかならラベルを使うなどして実行しない条件を設定するのが正だと思う。
すみません、リポジトリの公開を忘れました。現在は公開しました、再現する場所をもう一度を見てみますか。