April 9, 2024
この記事は以前Qiitaにて公開したものになります。
元記事はこちら : 再利用可能なワークフローを使ってみた
私の所属するチームではGitHub Actionsを使った各種自動化を実施しています。
Pull Requestの作成やブランチへのコミットなどに反応して、ユニットテストやLinterなどが実行されたり、アプリケーションがデプロイされるようになっています。
これによってレビューの手間が簡略化されたり、Pull Requestをリリースブランチにマージするだけでリリース作業を完結させられたりしています。
その一方で、年々CI/CDでやりたいことが増え、ワークフローの定義ファイルがどんどん長くなっていき、可読性やメンテナンス性が落ちていくことに悩んでいました。
今回はその悩みの解決のため、再利用可能なワークフローを活用してワークフローを分割したので、それについて書こうと思います。
私がメインで開発しているリポジトリには、
の処理を一気に行う巨大なワークフローが存在していました。
ひとつのファイルにまとまっていることで「ここを読めばなんとかなる」という状態ではあったものの、初めて触るメンバーにとっては敷居が高く、メンテナが固定化されてしまっていました。
また、これはワークフローの問題ではないのですが、一部テストコードがflakyなものになっており、ときおり失敗してはワークフローをすべて再実行するため十数分待ちということも発生していました。
そこで、再利用可能なワークフローを使って処理ごとにワークフローを分割し、
ことを試すことにしました。
再利用可能なワークフローとは、他のワークフローから呼び出し可能なワークフローです。
使い始めるのは簡単で、まず、再利用したいワークフローの発火条件を以下のようにします。
name: 再利用される側のワークフロー
on:
workflow_call:
# ほかにも発火条件を足したければ、普通に書く
# 以下、いつも通りにジョブやステップを書く
その後、呼び出し元のワークフローで、再利用したいワークフローのファイルパスを指定することで、呼び出せます。
# 省略
jobs:
reuse:
uses: ./github/workflows/reusable.yaml
似たものとして、カスタムアクションがあります。
カスタムアクションとの大きな違いは、
の2点になります。
詳細については、公式ドキュメントを参照してください。
今回のケースで、私はメインのワークフローから
を再利用可能なワークフローとして切り出し、
のそれぞれで、必要なものを呼び出すように変更を加えました。
最終的なファイル構成は以下のようになります。
.github
└── workflows
├── deploy.yml
├── integration.yml
├── syntax-check.yml
├── build.yml
├── backend-test.yml
├── frontend-test.yml
├── etc...
基本的には通常のワークフローをそのまま分けていけば動くので、再利用可能にすること自体はとても簡単です。
分割してしばらく経ってからこの記事を書いています。
経過を見た感想としては、以下のよかったこと、いまいちだったことがあると感じています。
再利用可能なワークフローはメリットも大きいですが、メンテナンス・課金回りでの影響・手間も発生してしまいます。
そのため、全員に手放しでおすすめというわけにはいきませんが、再実行性や見通しの悪さに悩まされている方は検討してみてはいかがでしょうか。