GitHub ActionsのAnnotation定点観測のためのCI活用事例
株式会社MIXIでサロンスタッフ予約サービス「minimo」のバックエンドエンジニアをしている鈴木です。
minimoではGitHubのOrganization内で発生しているGitHub ActionsのAnnotation (エラーやWarning) をどのように定点観測しているかについてまとめます。
なぜ定点観測したいか
非推奨な記法やNode.jsのバージョンに気づきやすくなる
この場合、記法の書き換えや古いNode.jsを使っているActionsのアップデートなどの対応を行う必要がありますが、普段使っていてもなかなか気づきにくいです。
そのため、定点観測できると早い段階でWarningに気づいて対処することが可能になります。
CIがエラーを吐いていることに気づきやすくなる
permissionの設定ミスなどでエラーが出ていてもCI自体は成功している場合、ミスに気づきにくいです。
また、scheduleで定期実行しているCIが何らかの要因である日を境に落ち続けているなど、CIが落ちていることに気づきにくいケースもあります。
定点観測できるとこれらも検知しやすくなります。
実現方法
実装
gh-annotationsを使うことで、GitHub Actionsの実行結果からAnnotationを取得できます。
これを使って、Organization内の全リポジトリのAnnotationを取得するCIを作成しています。
作成方法
-
https://docs.github.com/ja/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow#github-app-による認証 に従ってGitHub Appを作成します。なお、GitHub AppのアプリIDや秘密鍵はCIを配置するOrganizationやリポジトリ内で次のように保存します。
- アプリID: 構成変数
APP_ID
- 秘密鍵: シークレット
APP_PRIVATE_KEY
- アプリID: 構成変数
- 次のようなCIの定義ファイルを作成します。
name: Get GitHub Actions Errors
on:
# 主に手動実行することを想定
workflow_dispatch:
pull_request:
paths:
# 動作確認しやすいよう、自分自身に差分があるときはCIを実行する
- .github/workflows/get_github_actions_errors.yml
push:
branches:
- main
paths:
# 動作確認しやすいよう、自分自身に差分があるときはCIを実行する
- .github/workflows/get_github_actions_errors.yml
jobs:
get-github-actions-errors:
runs-on: ubuntu-latest
timeout-minutes: 5
steps:
- name: Install gh-annotations
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: gh extension install swfz/gh-annotations
# Organization内の全リポジトリを対象とするため、GitHub Appのトークンを使用する
- name: Generate a token
id: generate-token
uses: actions/create-github-app-token@df432ceedc7162793a195dd1713ff69aefc7379e # v2.0.6
with:
app-id: ${{ vars.APP_ID }}
private-key: ${{ secrets.APP_PRIVATE_KEY }}
# Organization内の全リポジトリを対象とするため指定
owner: ${{ github.repository_owner }}
- name: Get GitHub Actions Errors
env:
GH_TOKEN: ${{ steps.generate-token.outputs.token }}
run: |
get_errors() {
errors="$(gh annotations -json -repo "$1")"
# 既知のものであるなどの理由で無視したいAnnotationがある場合は次のコメントアウトを外し、「{無視したいエラー・Warningの絞り込み条件}」に無視したいAnnotationがヒットするような絞り込み条件を記載する
# 絞り込み条件例: 「Cache not found for keys:」で始まるWarningを無視したい場合は「startswith("Cache not found for keys:")」
echo "$errors" # | jq '.[] | select(.message | {無視したいエラー・Warningの絞り込み条件} | not)'
}
export -f get_errors
# CIの実行結果 (Summary) に結果を出力
{
echo '## GitHub Actionsのエラー・Warning'
echo '```json'
# 無視したいリポジトリがある場合はget_errors実行前に「grep -v org/repo」で除外する
gh repo list --limit 200 --json 'nameWithOwner' --no-archived ${{ github.repository_owner }} \
| jq -rc '.[]|.nameWithOwner' \
| xargs -I{} bash -lc "get_errors {}"
echo '```'
} >> "$GITHUB_STEP_SUMMARY"
使い方
-
https://github.com/org/repo/actions/workflows/get_github_actions_errors.yml
(org/repo
にはCIを配置したリポジトリ名を入れる) を開きます。 -
Run workflow
を開き、Run workflow
ボタンを押下します。 - CIの実行が終わったら、CIの実行結果 (Summary) を開き、
GitHub Actionsのエラー・Warning
欄に記載されているOrganization内の全リポジトリのエラー・WarningのJSONを確認します。
定点観測方法
minimoではインフラをよく触っているエンジニアによる週1の定例があり、そこでインフラのメトリクスや料金を確認しています。
その際の確認項目としてこのCIもリストアップされており、その場でCIを実行することで、対応が必要なGitHub ActionsのエラーやWarningがないかを定点観測しています。
このようにすることで、無理なく定点観測ができているように感じます。
宣伝
minimoでは一緒に働く仲間を募集中です!
リモート勤務も可能ですので、詳しくは下記採用ページをご確認ください。
Discussion