<

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

GitHub Actions
DevOps
GitHub
Survey

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

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

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

GitHub Actions で使用するもの

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

https://docs.github.com/ja/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event

このトリガーは、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 です。

https://github.com/stefanzweifel/git-auto-commit-action

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 を、紹介します。

repositoryやること
username/frontendi18n のメッセージファイルを利用
username/messagei18n のメッセージファイルを管理
 
# <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

<Image
	src="https://res.cloudinary.com/silverbirder/image/upload/v1693363969/silver-birder.github.io/blog/lunch_2x.png"
	width={604}
	height={801}
	layout="constrained"
	alt="xkcd"
/>

`@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 で、他のワークフローをトリガーできない

https://github.com/orgs/community/discussions/27028

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

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

https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows#workflow_run

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

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

https://github.com/peter-evans/repository-dispatch#client-payload

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

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

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

終わりに

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

役立ったら、☕でサポートしてね！

シェアしよう

関連するタグ

GitHub Actions
DevOps
Survey