GitHub Actions

2020年10月、ONNX-MLIRという機械学習コンパイラ（ONNXモデルを実行可能バイナリへ変換するツール）に macOSのCI設定を追加するPRを送り、マージされました。 本記事では、このPRを作成してからマージされるまでの試行錯誤を紹介します。 経緯 OSS機械学習コンパイラの調査の一環でONNX-MLIRを見つけ、開発用PC(macOS; MacBook Pro 13")に導入していました。 リポジトリ内を見ていたところ、x86-Linux、s390-Linux、x86-WindowsのCIは走っていますが、どうやらmacOSのCIはないみたいでした。 Issueに「macOS向けCIパイプラインを追加しようと思ってるけどどう？」と聞いてみたところ、 メンテナの一人から是非やってやって欲しい旨のコメントがあり、作業に着手しました。 CIサービスの選定 GitHubをサポートしているCIサービスはいくつかありますが、メンテナからはTravis CIでやって欲しいとの要望があったため、 Travis CI向けの調査に着手しました。 ONNX-MLIRでは、ビルドにDockerを使っています。 単一のDockerイメージでビルドするのではなく、以下のようにビルドを2段階に分ける構成とすることで、 依存ライブラリのビルド成果物を再利用可能となり、ビルド時間の短縮を実現しています。 依存ライブラリをビルドするDockerイメージ llvm/mlirが一番大きな依存ライブラリで、ビルドに1時間程度かかる 依存ライブラリの更新時にビルドされる 上記でビルドした生成物を使ってONNX-MLIR本体をビルドするDockerイメージ このイメージはTravis-CI実行時に毎回ビルドされる Travis CIとDockerのmacOSサポート状況を調査したところ、 DockerはゲストOSとしてのmacOSをサポートしていない（多分） Travis CIのmacOS環境はDockerをサポートしていない（Using Docker in Builds） ため、Travis CIは使えないと判断しました。 ただ、実現したいことは「キャッシュ機構による高速化」であることは分かった、代替案の調査に着手しました。 別のCIサービスとしてGitHub Actionsを調査したところ、キャッシュ機構(actions/cache@v2)をサポートしており、これを提案しようと考えました。 （今考えると、Travis CIのキャッシュ機構を使えば同じことができますね。。。） しかし、GitHub Actionsのキャッシュ機構は以下の制約があるとわかりました。 7日間以上アクセスのないキャッシュエントリは削除される リポジトリ全体でキャッシュサイズの上限が5GB 上記の制約があるが、GitHub Actionsは使えそうとのことをメンテナに相談したところ、 1.の制約は問題なく、2.が大丈夫ならGitHub Actionsを使おうとのコメントをもらいました。 というわけで、キャッシュ対象のファイルサイズの調査をします。 actions/cache@v2調査 キャッシュ対象のファイルサイズの調査の前に、どのようにキャッシュされているか知るためにactions/cache@v2を調査します。 GitHub Actionsは、リポジトリ全体でキャッシュサイズの上限が5GBという制約があります。 実はこのサイズは、キャッシュ対象の圧縮後のサイズを指しています。（公式ドキュメントには記載がなく、ソースコードを読むとわかりました） 以下のようにコードを読んでいくと、キャッシュ対象はGzip or zstdで圧縮されることがわかります。 キャッシュ保存時に呼ばれるメソッドはsaveCache()を呼び出しています。 https://github....