GitHub Actionsで依存関係のあるレポジトリ間で、 他のレポジトリのworkflowを動かして結果を見てみたい時、 直接他のレポジトリのworkflowにtriggerをかけて動かしてみる方法について。
- Create a workflow dispatch event
- Tokenの取得
- Tokenの登録
- Workflow IDの取得
- APIを使ったworkflowの実行
- Trigger Workflow and Wait Actionを使う
Create a workflow dispatch event
GitHub ActionsのAPIにdispatches
というものがあり、これを使って
workflowを送り出してやることが出来ます。
GitHub Actionsのページからボタンを使って実行できるようになるものですが、 この設定が入ったworkflowがあるとAPI経由で実行することも出来るようになります。
というわけで、workflowに適切なTokenを渡した上でこのAPIを叩いて上げれば他のレポジトリのworkflowを実行できます。
追記: 2023/02/27
workflow_dispatch 以外にrepository_dispatch というトリガーもあります。
こちらもAPI経由で実行することが可能です(APIは別)。
repository_dispatchとworkflow_dispatchの主な違いは
- repository_dispatch
- 手動実行できない
- ブランチはデフォルトブランチに限る
- workflow_dispatch
- 手動実行が出来るようになる
- ブランチ(もしくはタグ)は
ref
で指定可能
追記ここまで
Tokenの取得
レポジトリのActionsへの書き込みの権限がほしいわけですが、 最近レポジトリ単位で細かく権限が設定できる fine-grained personal access tokens というものが使えるようになったのでそれを使ってみます。
Introducing fine-grained personal access tokens for GitHub The GitHub Blog
まだ現時点でもベータ版になっていますが古いものと並行して使えるようになっています。
Fine-grained Personal Access Tokensのページへ行き 1 Generate new tokenボタンを押して新しいtokenを発行。
この際、Fine-grainedの方だとアプリを使った追加認証などが求められるようになっています。 (古い方のものでは要求されない。)
また、古いほうだとNo expirationが選べましたがFien-grainedの方では最大で1年までの期限付きしか選べなくなっています。
大きな違いは
- Public Repositories (read-only)
- All repositories
- Only select repositories
というものから選べて、Tokenを適用するレポジトリの範囲を決める事ができます。 Only Selectでは1つのTokenで最大50個のレポジトリを選ぶ事が出来ます。
単に公開されている情報をAPI経由で取得したくてrate limitを上げたいだけの場合などは Public Repositories (read-only)にしてpermissionを何も付けずに Tokenを取得すればOKです。
ここでOnly select repositoriesを選んで今回workflowを他からAPIで呼び出したいレポジトリを選んでおきます。
その下でPermissionsの項目で必要なものをNo access
、Read-only
、Read and write
の中から選べるようになっているので
一番上のActionsをRead and write
にします。
これを選択するとMetadataのRead-only
もmandatory
として自動的に有効になります。
今回はこれら以外はすべてNo access
のままで、Generate tokenしてTokenを取得します。
Tokenの登録
取得したTokenをトリガーを発行したい元のレポジトリのActions secretsに登録します。 Settingsのページの左の欄の中のSecrets and variablesを開いてActionsのページを開くと Actions secrets and variablesの管理ページに行くのでNew repository secretボタンから先程取得したTokenを設定します。
変数名は適当にトリガーをかける先のレポジトリ名とか使ってREPO_DEST_TOKEN
とか。
この名前にGITHUB_
というプレフィックスをつけようとすると駄目だと怒られるので別の名前に。
Workflow IDの取得
このステップは後の Trigger Workflow and Wait Actionを使う場合にはスキップして大丈夫です。
Workflowを呼ぶためにIDが必要になります。このIDはAPIを使って
https://api.github.com/repos/rcmdnk/python-action/actions/workflows
みたいなURLを開くと
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
といった感じの情報が得られるのでこのid
になります。
APIを使ったworkflowの実行
ここまで来たらあとは
workflowの中で${{ secrets.REPO_DEST_TOKEN}}
を使って
1 2 3 4 5 |
|
のようにAPIを叩いて上げれば実行出来ます。
rcmdnk/repo_dest
はdispatchしたいworkflowのあるレポジトリ、
test.yml
は.github/workflows
にあるworkflowの設定ファイル名です。
(拡張子も含める。)
Trigger Workflow and Wait Actionを使う
IDを取得したりcurlとかで色々書くのがちょっと面倒ですが、 このようなことを行うためのActionがMarketplaceに公開されているのでそれを使うと簡単に設定できます。
workflowの中で以下の様なstepを追加するだけ
1 2 3 4 5 6 7 |
|
owner
にレポジトリのユーザー名、repo
にレポジトリ名を与え、
workflow_file_name
でworkflowのファイル名を指定してあげればworkflow idも勝手に取得してくれます。
あとは先程取得したTokenをgithub_token
に渡してあげるだけ。
propagete_failure
は実行したworkflowのの成否をこのstepの成否として使いたい場合にtrue
に設定します。
もし失敗してもこちらのworkflow側では失敗として扱わない場合は必要ありません。
他には
ref
: ブランチ名など。デフォルトはmain
。client_payload
:workflow_dispatch
がinputs
を保つ場合はここにjson形式で値を渡せます"{\"option_a\": \"abc\", "{\"option_b\": \"xyz\"}"
みたいな感じで。
wait_interval
: ジョブの結果を確認する頻度。デフォルトは10秒間隔。github_user
: Tokenの所有者のユーザー名- これはworkflowの結果を取得する際に使われるもので通常使う事はないです。
- workflowを実行する際にトリガーをかけたユーザー名を変更できると思って区別できる名前を付けたらtokenの所有者と別名となって結果の取得が延々と出来ない状態になってしまいました。
などのオプションがります。
実行すると
1 2 |
|
みたいなログが結果が出るまで出続けて、結果が出ると
1 2 |
|
みたいな感じでジョブのURLも出してくれます。
この辺の結果の確認まで自動で行ってくれるのが嬉しいところです。
Ref:
- Triggering by other repository · Discussion #26323 · community
- Trigger Another Repository’s Github Action Workflow and Wait for Result
-
SettingsDeveloper settings でPersonal access tokensの中にあるFine grained tokens (beta)を選択 ↩