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