GitHub ActionsとPull Requestを活用した、同期の自動化

あけまして、おめでとうございます。神社のおみくじで、人生はじめて大吉を引きました、silverbirder です。

普段の業務で、Figma のデザイントークンや API のスキーマファイル、i18n のメッセージファイルなどを、フロントエンドへ同期するコミュニケーションが不毛に感じています。そこで、GitHub Actions と Pull Request を活用して、同期コミュニケーションを削減する仕組みを紹介します。

目新しい情報はないかもしれませんが、同じお困りごとを持つ人へ助けになれば、幸いです。

GitHub Actions で使用するもの

今回紹介する仕組みの核となるのが GitHub Actions の repository-dispatch トリガーです。

リポジトリの REST API エンドポイント - GitHub ドキュメント

REST API を使って、GitHub 上のリポジトリを管理します。

docs.github.com

このトリガーは、GitHub API を経由して、GitHub Actions のワークフローを起動することができます。そのため、次のように 異なるリポジトリでの GitHub Actions ワークフローを連携できます。

repository-dispatch と create-pull-request は、次の GitHub Actions です。

https://github.com/peter-evans/repository-dispatch https://github.com/peter-evans/create-pull-request

• respository-dispatch
  • repository-dispatch-event を dispatch する Action
• create-pull-request
  • Pull Request を作成する Action

これらの GitHub Actions を使わずに gh などを使って代替できますが、便利なモノを使って楽をします。

GitHub リポジトリ以外からのトリガー

GitHub のリポジトリ(username/other)からトリガーだけでなく、他のサービスからでもトリガーできます。例えば、Google Sheets からだと、Google Apps Script から GitHub API を呼べばよいです。

他にも、Kibela の outgoing webhook を、Server が受けて、Server が GitHub API を呼び出す方法があります。

Server は、IFTTT や Zapier のようなサービスでも良いですし、自前のサーバーでも良いでしょう。

自動 commit

schema ファイルから、型を生成したい(yarn codegen)こともあると思います。そういうときは、次のフローを追加します。

git-auto-commit-action は、変更したファイルを git commit するだけの Action です。

GitHub - stefanzweifel/git-auto-commit-action: Automatically commit and push changed files back to GitHub with this GitHub Action for the 80% use case.

Automatically commit and push changed files back to GitHub with this GitHub Action for the 80% use case. - stefanzweifel/git-auto-commit-action

github.com

create-pull-request だけでも、自動 commit することができます。私は、次のケースで使用しました。

• Figma のDesign Tokensで、Figma 上から Pull Request を作成する。
  • GitHub Actions で、style dictionary の build したものを commit したい

on:
  pull_request:
    types: [opened]
jobs:
  update:
    if: startsWith(github.head_ref, 'figma/')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm ci
      - run: npx style-dictionary build
      - uses: stefanzweifel/git-auto-commit-action@v4

Preview

Figma のデザイントークンや、i18n のメッセージファイルを更新したとき、Preview できる仕組みがあると、画面の確認ができて、良いです。

例えば、vercel や chromatic の preview です。

https://vercel.com/docs/concepts/deployments/preview-deployments https://www.chromatic.com/docs/review

サンプルコード

i18n のメッセージファイルをフロントエンドへ同期する GitHub Actions を、紹介します。

## <username/message>/.github/workflows/main.yml
on:
  push:
    branches:
      - main
    paths:
      - "i18n/**"
jobs:
  dispath:
    name: Setup
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: peter-evans/repository-dispatch@v1
        with:
          repository: username/frontend
          token: ${{ secrets.PAT }}
          event-type: create-pull-request-message
          client-payload: '{"ref": "${{ github.ref }}"}'

## <username/frontend>/.github/workflows/main.yml
on:
  repository_dispatch:
    types: [create-pull-request-message]
jobs:
  createPullRequest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/checkout@v3
        with:
          repository: username/message
          ref: ${{ github.event.client_payload.ref }}
          path: "tmp/"
      - run: |
          mv tmp/message.json src/message.json
          rm -rf tmp
      - uses: actions/setup-node@v3
      - run: npm ci
      - run: yarn generate:message
      - uses: peter-evans/create-pull-request@v4

受け入れテストをマークダウンで管理

安心してマージできるように、受け入れテストを整備しておきましょう。

具体的には、cucumberで仕様書をMarkdown(MARKDOWN_WITH_GHERKIN)で管理します。

例えば、次のような仕様書です。

## Feature: Staying alive
 
This is about actually staying alive,
not the [Bee Gees song](https://www.youtube.com/watch?v=I_izvAbhExY).
 
## Rule: If you don't eat you die
 
![xkcd](https://res.cloudinary.com/silverbirder/image/upload/v1693363969/silver-birder.github.io/blog/lunch_2x.png)
 
`@important` `@essential`
 
### Scenario Outline: eating
 
- Given there are <start> cucumbers
- When I eat <eat> cucumbers
- Then I should have <left> cucumbers
 
#### Examples:
 
| start | eat | left |
| ----- | --- | ---- |
| 12    | 5   | 7    |
| 20    | 5   | 15   |

この Markdown も、GitHub Actions で Pull Request するフローに載せましょう。新しいシナリオが追加された場合、(cucumber のライブラリ上) テストコードが存在しないとエラーとなります。

機能で担保したいシナリオを Markdown で管理していくことで、次のメリットがあります。

• 仕様が明確になる
• CI で受け入れテスト(cucumber)を動かし成功すると、仕様を満たす状態 となる

ハマったこと

GitHub Actions Bot の commit で、他のワークフローをトリガーできない

Github actions workflow not triggering with tag push · community · Discussion #27028

I have a workflow with 2 actions. The first action is triggered when a push is made to the branch and pushes new git tag and the second action is triggered when after a new tag is pushed. However, ...

github.com

token に、PAT を渡すように変更すれば解決します。

他の解決策としては、workflow_run のトリガーを使えます。

ワークフローをトリガーするイベント - GitHub ドキュメント

GitHub で特定のアクティビティが発生したときに、スケジュールした時刻に、または GitHub の外部でイベントが発生したときに、ワークフローが実行されるように構成できます。

docs.github.com

ただし、デフォルトブランチでのみ動作します。

repository-dispatch の POST は、JSON で制限がある

GitHub - peter-evans/repository-dispatch: A GitHub action to create a repository dispatch event

A GitHub action to create a repository dispatch event - peter-evans/repository-dispatch

github.com

同期したいファイルを json に変換して、dispatch する event ペイロードに含めようと、当初考えていました。ただ、次の懸念があったため、却下しました。

• json にしてしまうとコメントが消える
• JSON のバイトサイズに上限がある

そこで、同期したいリポジトリの github.ref を event ペイロードに含めて、event を受けた側がソースコードをチェックアウトして使う方針に切り替えました。

終わりに

GitHub Actions と Pull Request を活用することで、自動的にアプリケーションのソースコードを更新する仕組みを簡単に組み立てられます。 このような Ops があれば、Slack でのメッセージラリーをする回数が減らせられます。ぜひ、ご活用ください。