GitHub Actions のワークフロー内のpushで別のワークフローをトリガーする方法のメモ

Actionsすこすこ系エンジニアのtaconaです。
自動化。いいですよね。作りたてのCIが無事にPassした時の快楽物質の放出量に時々自分でも驚いてます。

このサイトについてもGitHubでコードを管理していて、リリースやLint、ビルドチェック、VRTなどなど様々な処理を自動化しています。
とはいえ個人サイトなのであんまりワークフローを連発しすぎるとActionsの月間の無料枠（2,000分）を越えかねないので、必要なものを必要な時だけ動かしたいなと思っていました。

その際、特定のActionsが別のActionsをトリガーしたい場合にデフォルトで利用可能なGITHUB_TOKENを使っていると正常にトリガーできない仕様に直面したので、その解決策を備忘録的にメモしていきます。

やりたいこと

• リリースPRを作成するワークフローを手動実行する
  • 実行時に指定したバージョンにあげるcommitをpushし、Pull Requestを作成する
• 上記のワークフローのpushをトリガーにビルドチェック用のワークフローやVRT用StorybookのChromaticデプロイワークフローを実行する

細かい要件は省略しますが、上記のように「ワークフロー内のpushによってpushがトリガーになっている別のワークフローを発火させる」ということを実現する必要がありました。

発生した問題

Triggering a workflow | GitHub Docs に以下のような記載があるように、デフォルトで利用可能なGITHUB_TOKENを利用してpushなどの操作を行っている場合は別のワークフローがトリガーできない仕様になっています。

リポジトリGITHUB_TOKENを使用してタスクを実行する場合、 GITHUB_TOKEN によってworkflow_dispatchトリガーされるイベント (例外) と repository_dispatch、 は新しいワークフロー実行を作成しません。 これによって、予想外の再帰的なワークフローの実行が生じないようになります。

これによって、Pull Requestを作成するワークフロー上でpush操作を行っていても、pushがトリガーになっているワークフローが実行されない状態になっていました。

解決方法

解決方法としては大きく2パターンあるっぽいです。

• 解決策その1: Personal Access Tokenを使う
  • 対象のリポジトリに限らず、当該アカウントでアクセス可能な全てのリポジトリに対してスコープが適用されてしまうため非推奨
  • また、有効期限をつける場合は手動で再生成、紐付けをする必要があるためその意味でも非推奨
  • 有効期限をつけない場合は更に安全性が低いため尚のこと非推奨
• 解決策その2: GitHub Appsを使う
  • 細かくPermissionの指定が可能
  • リポジトリにAppをインストールする形で利用するので使いたいリポジトリに影響を絞れる
  • App作成者のみインストール可能にできるため安全性が高い
  • Appによって作成したtokenは有効期限があるため漏洩リスクが引く

といった感じでPersonal Access Tokenを推奨する理由が何一つ無さそうでした。

今回はGitHub Appsを使う場合の手順を簡単にまとめます。

手順

1️⃣ GitHub Apps作成

GitHub AppsからNew GitHub Appを押して新しいAppを作成します。
アプリ名や概要などはそれぞれ任意で入力しておいて、以下の設定をしておきます。

• Webhook > Active をオフにする
• Permissions > Repository Permissions で以下の設定をする
  • ContentsをRead and writeにする
  • そのほか、PR作成までする場合はPull RequestsをRead and writeにするなど、ワークフローの内容に沿って権限を付与する
• 必ずOnly on this accountを選択した状態で作成する

2️⃣ 作成したAPPのID / Private Keyを控えておく

GitHub Appの作成が完了したら、まずはそのAppのIDを控えておきましょう。（AppのGeneral画面の冒頭らへんにある6桁程度の数列）

次に、同じ画面の下部でGenerate a private keyをして秘密鍵ファイルをダウンロードします。

3️⃣ 対象のリポジトリのActions secretsでAPPのID / Private Keyを登録

リポジトリのSettings > Secrets and variables > Actions からGitHub Actions向けのSecretsを登録できるので先ほどのAPPのIDおよびPrivate Keyを登録します。
キー名はなんでもいいです。Secretsがアルファベット順でソートされるので順序が揃うように僕の場合は以下のようにしました。

• TACONASU_APP_ID: GitHub AppのAPP_ID
• TACONASU_PRIVATE_KEY: GitHub AppのPrivate Key

また、Private Keyは生成時にpemファイルとしてダウンロードされますが、秘密鍵を確認する際は以下のようなコマンドで確認してください。

cat <pemファイルのパス>

出力された文字列をそのままSecretsに貼り付けてください。（ -----BEGIN RSA PRIVATE KEY----- から -----END RSA PRIVATE KEY----- まで）

4️⃣ トリガー元のWorkflowでAPPのトークンを利用して実行

GitHub Actions内でAppのトークンを利用してリポジトリに対する操作をしたい場合、actions/checkoutのtokenオプションでトークンを渡すことで、それ以降のリポジトリに対する操作で利用されるようになります。

また、AppのIDおよびPrivate Keyからトークンを生成するにはactions/create-github-app-tokenを使います。

以下はAppのトークンを使ってcheckoutまでをするワークフローのサンプルです。

name: 🚀 Sample Workflow
on:
  workflow_dispatch

jobs:
  sample:
    name: Sample Workflow
    runs-on: ubuntu-latest
    steps:
      # GitHub App の ID / Private Key を使ってトークンを生成する
      - name: Generate a token
        id: generate-token
        uses: actions/create-github-app-token@v1
        with:
          # Actions Secrets のAPP_IDを登録したキー名
          app-id: ${{ secrets.TACONASU_APP_ID }}
          # Actions Secrets のPrivate Keyを登録したキー名
          private-key: ${{ secrets.TACONASU_PRIVATE_KEY }}
      # 前のstepで生成したトークンを指定してcheckoutする
      - uses: actions/checkout@v4
        with:
          token: ${{ steps.generate-token.outputs.token }}
      # 後続のstepでpushとかPR作成とか好きなことをする

あとはワークフローを実行し、無事に別のワークフローがトリガーされていれば成功です😉

おわり

GitHub Appの使い方としてActions向けに一時的なトークンを発行するっていう使い方があるの知らなかった〜〜〜。
そもそもApp自体を使ったことがなかったけど、Permissionsも結構柔軟に指定できるし色々使い道がありそうなので業務効率化目的での活用方法を模索してみるのありかも。

＿人人人人人＿
＞　ﾉᕱ_ᕱ　 ＜
＞　( ╹ω╹) ＜ ｷﾞｯ   ﾊｯ   ﾌﾞｯ
＞　(　 (7 ＜        ﾜｯ   ﾛｯ
＞　＜　ヽ　＜
￣^Y^Y^Y^￣