プロジェクトに GitHub Actions を導入する方法
一言で表す GitHub Actions
GitHub 組み込みの CI/CD。

はじめに
かつて CI を導入する際、チーム内では CircleCI、DroneCI、Jenkins などのソリューションをめぐって議論(あるいは喧嘩)に時間を費やしていたかもしれない。だが、チームのコードが GitHub でホスティングされているなら、GitHub と簡単に CI を統合できる。万能薬や決定打とまでは言えないかもしれないが、テストの実行や push and deploy といった一般的なシナリオであれば、かなり手軽に実現できると僕は思っている。以下で詳しく紹介しよう。
導入方法
コードのルートディレクトリに .github/workflows/your-workflow.yml という設定ファイルを追加するだけでいい。
関連リソース
始める前に、公式ドキュメントのリンクをいくつか確認して手順通りに進めるほうが早いかもしれない。まずはドキュメントを読んでから手を動かしたい人は参考にしてみてほしい:
- ガイド:https://github.com/features/actions
- ドキュメント:https://help.github.com/en/actions
- GitHub Actions パッケージ(Marketplace):https://github.com/marketplace?type=actions
自分のプロジェクトに GitHub Actions を追加する方法
1つの workflow の中には複数の jobs があり、job 自体は複数の step で構成される。step は GitHub Action であったり、コマンドの実行だったりする。大まかには以下のような例になる:
name: your-name
# 可以使用的事件直接參考文件
# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#on
on:
push:
branches:
- master
paths-ignore: # 有時候不想要改個文件也觸發 github actions,可以用這個 ignore
- 'docs/**'
- 'README.md'
- 'LICENSE'
- 'CONTRIBUTING.md'
branches-ignore:
- 'xxxx'
tags-ignore:
- 'v1.*'
env: # 塞 env variable
PROJECT_ID: ${{ secrets.PROJECT_ID }}
RUN_REGION: asia-northeast2
SERVICE_ACCOUNT: ${{ secrets.SERVICE_ACCOUNT }}
jobs:
setup-build-and-deploy:
name: Setup gcloud and deploy
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
with:
version: '290.0.1'
project_id: ${{ secrets.PROJECT_ID }}
service_account_email: ${{ secrets.SA_EMAIL }}
server_account_key: ${{ secrets.SA_KEY }}
export_default_credentials: true
- name: Deploy
run: |-
echo $SERVICE_ACCOUNT > /tmp/key.json && \
gcloud auth activate-service-account --key-file /tmp/key.json && \
gcloud app deploy --project "$PROJECT_ID"
より高度な使い方として、ランタイム時に動的な判定を行いたい場合はこのように書くことができる:https://help.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions
env:
my_env_var: ${{ ALPHA ? 'A' : 'B' }}
GitHub Actions の実行時には、自動的にいくつかの context が注入される。
## 環境変数
環境変数はプロジェクトの Secret 内で設定できる。デフォルトでは Collaborator のみ閲覧可能で、他のユーザーが Pull Request 経由で Secret を GitHub Actions に流し込むことはできないようになっている。

この記事は GitHub Actions の使い方に関する簡単なメモであり、次回設定するときにはよりスムーズに行えるはずだ。
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。