GitHub Actionsというと、
- テスト
- ビルド
- デプロイ
をイメージする人が多いと思います。
もちろんCI/CDでも活躍しますが、実際に運用してみると、それ以外にも自動化できることが数多くあります。
この記事では、実務で導入して便利だったWorkflowを紹介します。
ブランチの自動削除
マージ済みのブランチを放置していると、
- ブランチ一覧が見づらい
- 不要なブランチが増える
- 間違えて古いブランチを使ってしまう
といったことが起こります。
そこで定期実行のWorkflowを用意し、
- マージ済み
- 一定期間更新されていない
ブランチを自動で削除しています。
GitHub Actions
↓
ブランチ一覧取得
↓
削除条件判定
↓
gh api
↓
ブランチ削除
GitHub CLIの gh api を利用してブランチを削除することで、安全に運用できています。
Self-hosted Runnerのクリーンアップ
Self-hosted Runnerを長期間運用していると、
- Actionsのキャッシュ
- ビルド成果物
- 一時ファイル
- ログ
などが蓄積し、ディスク容量を圧迫することがあります。
そのため、定期的に不要なファイルを削除するWorkflowを実行しています。
例えば、
rm -rf "$RUNNER_WORK_DIRECTORY/_work/*"
find /tmp -type f -mtime +7 -delete
必要に応じて、
- npmキャッシュ
- Composerキャッシュ
- Gradleキャッシュ
なども削除しています。
Runnerを安定して運用するためには、定期的なメンテナンスが欠かせません。
BacklogへPull Request通知
Pull Requestを作成しても、
気付かれずレビューが遅れることがあります。
そこで、
PR作成時にBacklogへ課題コメントを自動投稿しています。
Pull Request
↓
GitHub Actions
↓
Backlog API
↓
課題へコメント
例えば、
Pull Requestが作成されました。
URL
https://github.com/...
のようなコメントを投稿しています。
Backlog中心で運用しているチームでは便利でした。
Pull Requestリマインド
レビュー待ちのPull Requestが放置されることもあります。
そこで、
一定期間更新されていないPull Requestを定期的にチェックしています。
GitHub Actions
↓
PR取得
↓
更新日時確認
↓
Backlogへ通知
例えば、
3日以上更新がないPull Requestを対象にしています。
レビュー漏れを減らす効果がありました。
定期実行
運用系Workflowは、
cronで定期実行しています。
on:
schedule:
- cron: "0 1 * * *"
workflow_dispatch:
必要に応じて手動実行もできるようにしています。
GitHub APIを活用
これらのWorkflowでは、
GitHub APIやGitHub CLI（gh）を利用する場面が多くあります。
例えば、
- Pull Request一覧取得
- ブランチ一覧取得
- ブランチ削除
- Reviewer取得
- Issue取得
などです。
GitHub Actionsだけでは実現できない処理も、GitHub APIと組み合わせることで柔軟に実装できます。
Backlog APIも活用
BacklogとはAPI連携しています。
利用しているのは、
- 課題コメント追加
- 課題取得
- 課題作成
などです。
GitHubとBacklogを連携することで、
開発とタスク管理をつなげています。
導入して感じたこと
CI/CDだけでも十分便利ですが、
運用業務までGitHub Actionsへ任せることで、
日々の細かな作業がかなり減りました。
例えば、
- ブランチ整理
- Runnerメンテナンス
- PR通知
- レビューリマインド
など、人が忘れやすい作業ほど自動化の効果を実感しています。
まとめ
今回導入したWorkflowは次のとおりです。
- マージ済みブランチの自動削除
- Self-hosted Runnerの定期メンテナンス
- Pull Request作成時のBacklog通知
- 放置されたPull Requestのリマインド
GitHub ActionsはCI/CDツールという印象が強いですが、実際には開発だけでなく運用改善にも活用できます。
日常的に繰り返している作業をWorkflowに置き換えることで、ヒューマンエラーを減らし、チーム全体の開発効率を高められると感じています。