👷‍♂️

GitHub Actionsでワークフローをworkflow_dispatchで動かしながらデバッグ・開発していくときのおすすめの方法

2024/08/21に公開

解決したい課題

GitHub Actionsの開発がしたい。
ただ、GitHub Actionsはローカル環境がない。OSSでそういったことができるものも、実際の環境と差分があり、最終的には実際に動かしてみないとわからない。
そうなるとworkflow dispatchで随意に動かせると便利だが、

注: このイベントは、ワークフローファイルがデフォルト ブランチにある場合にのみワークフローの実行をトリガーします。

と書かれている通り、デフォルトブランチにワークフローファイルがないとworkflow dispatchは起動できない。
多くの開発ではデフォルトブランチへのマージはレビューを通さないといけないため、レビュー前に試行錯誤して完成させたいが、マージしないとそもそも試せないというジレンマが発生してしまう。

解決策

次のような、workflow_dispatchを起動できる、ミニマムのワークフローのみをデフォルトブランチへマージするPRを作り、マージする。

example.yml
name: 適当な名前(ただしデバッグ中は変えない)
on:
  workflow_dispatch:

jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello world!"

このようなワークフローがデフォルトブランチにマージされると、 適当な名前(ただしデバッグ中は変えない) という名前のワークフローがworkflow_dispatchできるようになる。

次に実際にこのワークフローを実装していくときは新たにブランチを切り、PRを作る。
これをデバッグする際は、先程可能になったworkflow_dispatchのメニューから、ブランチを指定して実行する。これでfeatureブランチで開発をしながら、任意のタイミングで実行してデバッグすることが可能になる。

ただし、この方法のときは name を変えないように注意する必要がある。
workflow_dispatchの実行対象はこの name プロパティで同一性を認識しているので、例えばファイルが同じでも name が異なる場合、別のワークフローと認識されて起動ができなくなる。

別解

example.yml
name: 適当な名前
on:
  push:

jobs:
  job1:
    ...

のように push を使う方法もある。この方法なら、先行してまずPRをマージする必要がない。
また、手動で毎回ワークフローを起動する手間もなくなる。

Discussion