🐺

actionsを管理する

2025/01/25に公開

はじめに

gitHub actionsで実行するworkflowを一箇所で管理する方法について模索してみました。

結論

共通のRepositoryからComposite Actionで書かれたaction.ymlsubmoduleとして登録し、workflowから呼び出す

common composite
submoduleで登録したmoduleにあるaction.ymlをworkflowで実行する全体像

作成背景

composite actionを実行するにあたり、実行するために必要なstepがいくつか必要でした。
consumerは、それぞれ必要なstepworkflowで定義するため
composite actionversion upする度に追従させる必要がありました。
※ 振る舞いは変更していないので、追従しなくても壊れることはない前提

same steps
Consumerはsetupに同じようなsteoを定義しているイメージ図

そこで、consumerの想定されるユースケースに合わせたcomposite actionを作成し、
それを共通のRepositoryから配布することで常に呼び出しを共通化できないか試みました。

Composite Actionの共通化

共通化するにあたり、composite actionが定義されているRepositoryとは別に ユースケースに合わせたactionファイルのみ定義されたRepositoryを作成します。

github submoduleによるモジュールの再利用

consumerは自身のRepositoryに、共通Repositorygit submoduleを利用して登録します。
登録後、submoduleを呼び出すworkflowを定義します。

# .github/workflows/test.yml
- name: Install dependencies
  uses: ./common_actions

uses:にはsubmoduleとして登録したモジュールに定義されているaction.ymlが格納されたディレクトリを指定します。

common module
Common Repositoryからsubmoduleで登録したイメージ図

このようにsubmoduleで登録することで、consumerは実行するために必要な設定を自身で管理することなく(具体を知ることなく)composite actionを実行できます。

考えの種

buildkitepipeline uploadのような動きを参考にしていました。

https://buildkite.com/docs/agent/v3/cli-pipeline#uploading-pipelines

検討事項

Composite Actionが定義されているRepositoryに書かない理由

composite actionが定義されたRepositoryに持たせると、submoduleで登録する際に必要以上のファイルをモジュール内に登録することになるため

ユースケースが増えた場合の対応

まず、共通化したRepositoryにユースケース毎のディレクトリを作成してaction.ymlを格納し、呼び出し側でディレクトリの指定を調整する方向で検討

# common Repository
├── usecase1
│   ├── action.yml
├── usecase2
│   ├── action.yml
# Consumer Repository
- uses: ./common_actions/usecase2

📝 MEMO

Discussion