step や job の実行を制御をする custom actions を作った話

この記事は GitHub Actions Advent Calendar 2023 の15日目の記事です。

3日目の投稿 に続き、またこれとは別に、表題のとおり step/job の実行を制御をする custom actions を作って公開したので、今回はその話をしたいと思います。

https://github.com/marketplace/actions/path-filter
↑ 先程 v2 をリリースしました。よかったら使ってみてください。

今回も、機能の話は薄めにして、開発にあたって考えたこと等を書きたいと思います。

作った経緯

この action の説明を一言ですると、指定したパスパターンのファイルがプルリクや任意のコミットの差分に含まれるか判定する為の action です。action 名は「Path Filter」としていますが、この名前は似たような概念のものである CircleCI の path-filtering や GiHub の paths filter に由来しています。

作ったきっかけは、CI の高速化に関する下記のような投稿を最近、目にしたことでした。

• ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜
• 成果物のハッシュ値を保存・比較して余計なデプロイを行わないようにする for GitHub Actions

私は普段、Android のエンジニアですので、ネィティブアプリ開発におけるビルドなど重たい CI のタスクを、コードに変更がなければスキップできるとよいと考えました。また昨今はモノレポであったり、Kotlin Multiplatform のようなマルチプラッフォーム向けの開発も世の中に増えてきているので、そういった様々な種類のコードが混在するリポジトリの CI において、変更したファイルに関係がないタスクをスキップできれば、CI の高速化に繋がりそうです。

既に Paths Changes Filter ( dorny/paths-filter ) や Changed Files ( tj-actions/changed-files ) などはあったのですが、事前にコードのチェックアウトが必要であったり（チェックアウト時の depth も注意が必要）、ファイル数の制限があったり、オプションがやたら多くて把握しきれなかったりするのと、ワークフローのイベント種別と適用される commit SHA の関係がよく分からず（私の README の読み込みが甘いという意見もあるかもですが、万人向けに理解しやすい内容でないことは事実）いったい何と何が比較されるんだろうという疑問があり、また、時には three-dot の比較がされるケースもあったりと、これは挙動を熟知していないと、使い方を誤りそうだなと思いました。もっとシンプルに利用できるものが欲しいなと。

また、Changed Files というのも自分は作っていて、一応この action でも同じようなことが出来はするのですが、GitHub API を利用していることに起因する 制約 があったので、この action はプルリク用（プルリクで使う分には制約はほぼ問題なし）と割り切って、今回の目的であるフィルタリングに特化した action を新しく作成することにしました。

作ってどうだったか

実装 ( action.yml ) を見て貰えれば分かるのですが、数十行という少なさで実装できました。やってることは、２つの commit SHA の git-diff だけなので、挙動やコード自体の把握も容易いかと思います。何か問題あれば、フォークして修正して使ってもらうのも簡単だと思います（報告を頂ければ対応はしますが^^;）。

性能に関しては、facebook/react のような公開されているコードで 2-3000 ファイルの差分で試しましたが、数秒（の前半代）で処理できたので、扱えるファイル数や速度に関しての問題はないのかなと思います。GitHub API を利用していないので、扱えるファイル数に関しては特に論理上の制限はありません。Ubuntu だけでなく macOS や Windows の runner でも動作確認しています。

主にやることは Git 操作なので、コードはシェルスクリプトベースで作成しましたが、パターンマッチングはシェルスクリプトだと辛そうだったので、その部分は actions/github-script と minimatch を利用しています。minimatch を採用したのは、単純に Labeler でも採用されていたという理由からです。

事前のコードのチェックアウトは不要なので、当然その depth を気にする必要もありません。とはいえ処理の内部的には、git-diff する為にコードの clone をしているのですが、job の作業空間を汚さないように、actions/checkout でチェックアウトされるであろう領域とは別の、この action 独自の領域に clone するようにしています。ですので、どのような job にでも安全にこの action を組み込むことが可能かと思います。

おわりに

コードも短く説明することもそんなに無いので、今回は以上となります。もし今回の action に関して、不具合とか気になる点がありましたらフィードバックを頂けると幸いです。