GitHubでプルリクエスト（PR）をマージする際、本文に Fixed #123 と書くと関連するIssueを自動で閉じてくれる便利な機能。
しかし、「マージしてデプロイした後に、実際の環境で試験をしないと完了と言えない」というケースも多いですよね。
「Fixedだと勝手に閉じちゃうし、かといってリンクを貼るだけだと管理が漏れる…」
そんな悩みを解決するために、今回は Fixed（即クローズ） と ToBeTested（試験待ちラベル付与） を使い分けるGitHub Actionsのカスタマイズ方法をご紹介します。
なぜ「Fixed」だけでは足りないのか？
GitHub標準の自動クローズ機能は非常に強力ですが、以下のような現場では「早すぎる」ことがあります。
- デプロイ後試験が必須: 本番や検証環境に反映されるまで動作確認ができない。
- 承認フローが別にある: コードはマージしたが、QA（品質保証）担当者の確認を待ってからCloseしたい。
そこで、「完全に終わったものは Fixed」、「マージ後に試験が必要なものは ToBeTested」とキーワードを使い分けることで、Issueのステータスを正しくコントロールできるようにします。
事前準備：標準の自動クローズをオフにする
まずは、GitHubが勝手にIssueを閉じないように設定を変更します。
- リポジトリの [Settings] タブをクリック。
- 左メニュー [General] を選択。
- 下へスクロールし、[Pull Requests] セクションにある 「Auto-close issues with merged linked pull requests」 のチェックを外します。
これで、キーワードを書いても勝手に閉じなくなりました。ここからがActionsの出番です。
GitHub Actionsで「使い分け」を実装する
次に、キーワードに応じて「クローズ」か「ラベル付与」を自動で行う設定ファイルを作成します。
リポジトリの .github/workflows/issue-control.yml として以下の内容を保存してください。
name: Issue Control by Keywords
on:
pull_request:
types: [closed]
jobs:
control-issue:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: read
steps:
- uses: actions/github-script@v7
with:
script: |
const body = context.payload.pull_request.body || "";
// "Fixed #123" があればIssueをClose
const fixedMatches = body.match(/Fixed\s+#(\d+)/gi);
if (fixedMatches) {
for (const match of fixedMatches) {
const issueNumber = match.match(/\d+/)[0];
await github.rest.issues.update({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issueNumber,
state: 'closed'
});
}
}
// "ToBeTested #123" があればラベルを付与
const testMatches = body.match(/ToBeTested\s+#(\d+)/gi);
if (testMatches) {
for (const match of testMatches) {
const issueNumber = match.match(/\d+/)[0];
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issueNumber,
labels: ['testing-required'] // ←事前に作成したラベル名
});
}
}
※事前にGitHubのLabels設定で testing-required（試験待ち）というラベルを作成しておいてください。
実際の運用フロー
この設定を導入すると、開発フローはこう変わります。
- パターンA：小さな修正・ドキュメント修正など
PRの本文にFixed #10と記載。
→ マージと同時にIssue #10 が Closed に。 - パターンB：デプロイ後の動作確認が必要な機能追加
PRの本文にToBeTested #11と記載。
→ マージ後、Issue #11 は Openのまま。
→ 自動で 「testing-required」ラベル が付く。
→ デプロイ後に試験を行い、問題なければ手動でClose！
まとめ
「自動化はしたいけれど、勝手に閉じられるのは困る」というジレンマは、GitHub Actionsでのキーワード検知でスマートに解決できます。
「試験待ち」のIssueが可視化されることで、リリース後の確認漏れも防げるようになります。ぜひ皆さんのチームでも取り入れてみてください。
コメント