actionsを管理する
はじめに
gitHub actionsで実行するworkflowを一箇所で管理する方法について模索してみました。
結論
共通のRepositoryからComposite Actionで書かれたaction.ymlをsubmoduleとして登録し、workflowから呼び出す
submoduleで登録したmoduleにあるaction.ymlをworkflowで実行する全体像
作成背景
composite actionを実行するにあたり、実行するために必要なstepがいくつか必要でした。
consumerは、それぞれ必要なstepをworkflowで定義するため
composite actionがversion upする度に追従させる必要がありました。
※ 振る舞いは変更していないので、追従しなくても壊れることはない前提
Consumerはsetupに同じようなsteoを定義しているイメージ図
そこで、consumerの想定されるユースケースに合わせたcomposite actionを作成し、
それを共通のRepositoryから配布することで常に呼び出しを共通化できないか試みました。
Composite Actionの共通化
共通化するにあたり、composite actionが定義されているRepositoryとは別に ユースケースに合わせたactionファイルのみ定義されたRepositoryを作成します。
github submoduleによるモジュールの再利用
consumerは自身のRepositoryに、共通Repositoryをgit submoduleを利用して登録します。
登録後、submoduleを呼び出すworkflowを定義します。
# .github/workflows/test.yml
- name: Install dependencies
uses: ./common_actions
uses:にはsubmoduleとして登録したモジュールに定義されているaction.ymlが格納されたディレクトリを指定します。
Common Repositoryからsubmoduleで登録したイメージ図
このようにsubmoduleで登録することで、consumerは実行するために必要な設定を自身で管理することなく（具体を知ることなく）composite actionを実行できます。
考えの種
buildkiteのpipeline uploadのような動きを参考にしていました。
検討事項
Composite Actionが定義されているRepositoryに書かない理由
composite actionが定義されたRepositoryに持たせると、submoduleで登録する際に必要以上のファイルをモジュール内に登録することになるため
ユースケースが増えた場合の対応
まず、共通化したRepositoryにユースケース毎のディレクトリを作成してaction.ymlを格納し、呼び出し側でディレクトリの指定を調整する方向で検討
# common Repository
├── usecase1
│ ├── action.yml
├── usecase2
│ ├── action.yml
# Consumer Repository
- uses: ./common_actions/usecase2
Discussion