Github アクションをプロジェクトに取り込む方法
一言で表す GitHub Actions
GitHub に内蔵された CI/CD。

概要
以前は CI を行うために、チーム内で CI のソリューションについて議論(時には衝突)する時間が必要でした。CircleCI、DroneCI、Jenkins などがその例ですが、チームがコードを GitHub 上でホスティングするだけで、簡単に GitHub と CI を統合できます。確かに、万全の策や決定的なツールとは言えませんが、一般的にテストを実行したり、push や deploy を行うような場面では、非常に簡単に実現できると思います。以下にその方法を紹介します。
導入方法
コードのルートディレクトリに .github/workflows/your-workflow.yml の設定ファイルを追加するだけで大丈夫です。
関連リソース
始める前に、いくつかのドキュメントリンクを直接紹介した方が早いかもしれません。とにかく、ドキュメントを読み終えてから手を動かしたい方は、以下を参考にしてください:
- ガイド:https://github.com/features/actions
- ドキュメント:https://help.github.com/en/actions
- GitHub Actions パッケージ: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: # 環境変数を設定
PROJECT_ID: ${{ secrets.PROJECT_ID }}
RUN_REGION: asia-northeast2
SERVICE_ACCOUNT: ${{ secrets.SERVICE_ACCOUNT }}
jobs:
setup-build-and-deploy:
name: gcloud のセットアップとデプロイ
runs-on: ubuntu-latest
steps:
- name: チェックアウト
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: デプロイ
run: |-
echo $SERVICE_ACCOUNT > /tmp/key.json && \
gcloud auth activate-service-account --key-file /tmp/key.json && \
gcloud app deploy --project "$PROJECT_ID"
もう少し高度な例として、runtime で動的に判断したい場合は、次のように書けます: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 を出し、どれだけ review を残し、どれだけ ticket を解決したかを集計し、数字で上司に成果を示そうとした。上司はただ、評価は成果だけで決まるわけではないと言った。数年後になって僕はようやく理解した——測定が目標になった瞬間、それはもはや良い測定ではなくなるのだと。イギリスの窓税からハノイのネズミ懸賞金、そして今日の PR 数による開発者評価まで、仕組みはまったく同じである。
- 画像のストレージと変換を Cloudflare Images に任せる Web ページに画像を一枚置くのはフロントエンドで一番簡単なことだ。でもそれをちゃんとやる——リサイズし、各フォーマットを生成し、トラフィックにも耐える——となると、実はひとつの解決策まるごとになる。だから僕は結局、原画一枚だけ渡して全部 Cloudflare Images に任せた。
- Access Keyはもう使うな Access KeyはAWSで見落とされがちなセキュリティリスクだ。OIDCとIAM Roleを組み合わせれば、GitHub Actionsはsecretなしで安全にAWSリソースを操作できる
- データベースの主キー: AUTO_INCREMENT、UUID、UUIDv7 バックエンド開発では主キーをどうするかをよく決める必要がある。auto increment か UUID か、衝突はどうするか、UUIDv7 と created_at + index の性能差はどれくらいか。実際に 2000 万件のデータで検証し、設計判断までまとめる。