From 79594ee48605908a29cf8269911aad35bbd2031d Mon Sep 17 00:00:00 2001 From: ryz310 Date: Tue, 24 Feb 2026 21:22:45 +0900 Subject: [PATCH] Update dependabot auto-merge runbook workflow --- docs/runbooks/dependabot_pr_auto_merge.md | 40 +++++++++++++++++------ 1 file changed, 30 insertions(+), 10 deletions(-) diff --git a/docs/runbooks/dependabot_pr_auto_merge.md b/docs/runbooks/dependabot_pr_auto_merge.md index d8cf19ab..35a240be 100644 --- a/docs/runbooks/dependabot_pr_auto_merge.md +++ b/docs/runbooks/dependabot_pr_auto_merge.md @@ -4,13 +4,22 @@ This runbook standardizes how to review Dependabot pull requests for GitHub Actions updates and safely enable auto-merge. ## Scope -- Target: Dependabot PRs that update GitHub Actions versions (for example, `actions/upload-artifact`). +- Target: PRs created by Dependabot that update GitHub Actions versions (for example, `actions/upload-artifact`). - Primary workflow file in this repository: `.github/workflows/ci.yml`. +- This runbook is for PR operation only, so creating a dedicated local work branch is normally unnecessary. ## Prerequisites - `gh` CLI is authenticated and can access `ryz310/my_api_client`. - You have permission to comment on and merge PRs. - Branch protection rules and required checks are configured on GitHub. +- Before starting the runbook, update local `master` and re-read `AGENTS.md`. + +```bash +git checkout master +git fetch origin +git pull --ff-only origin master +sed -n '1,260p' AGENTS.md +``` ## Step-by-step 1. Open PR metadata and changed files. @@ -19,35 +28,45 @@ This runbook standardizes how to review Dependabot pull requests for GitHub Acti gh pr view --json number,title,author,baseRefName,headRefName,files,body ``` -2. Review the exact diff and identify action version changes. +2. Validate that the PR is in scope. +- Confirm `author.login` is `app/dependabot`. +- Confirm changed files are GitHub Actions workflow/dependabot update files and the update target is GitHub Actions. +- If either condition is not met, stop this runbook and notify the user that manual review is required. + +3. Review the exact diff and identify action version changes. ```bash gh pr diff ``` -3. Compare old and new action versions and summarize impact. -- Focus on major version changes and runtime requirements (Node version, runner minimum version, breaking changes). -- For `actions/upload-artifact`, verify compatibility notes in the official release notes. +4. Summarize impact from the diff and release notes. +- Explain what functional changes are introduced by each action version bump. +- Explain whether existing workflows are affected (runtime requirements, minimum runner version, breaking changes, behavior changes such as credential handling). +- For major version updates, verify compatibility notes in the official release notes. +- Post this summary to the user and ask for explicit approval to proceed. -4. Enable auto-merge with squash merge. +5. Only after user approval, enable auto-merge. +- Use repository default merge method unless there is an explicit instruction to force squash merge. ```bash -gh pr merge --auto --squash +gh pr merge --auto +# Optional (only when squash is explicitly required): +# gh pr merge --auto --squash ``` -5. Check merge state. +6. Check merge state. ```bash gh pr view --json state,mergeStateStatus,autoMergeRequest ``` -6. If state is `BEHIND`, request Dependabot rebase. +7. If `mergeStateStatus` is `BEHIND`, post a Dependabot rebase comment (also only after user approval from Step 4). ```bash gh pr comment --body "@dependabot rebase" ``` -7. Re-check status until the branch is up to date and required checks pass. +8. Re-check status until the branch is up to date and required checks pass. ```bash gh pr view --json state,mergeStateStatus,statusCheckRollup,autoMergeRequest @@ -58,6 +77,7 @@ gh pr view --json state,mergeStateStatus,statusCheckRollup,autoMerge - `mergeStateStatus` is not `BEHIND`. - Required CI checks are green. - PR is merged automatically, or clearly waiting only on pending required checks. +- The user-approved impact summary is recorded in the operation log/comment thread. ## Failure handling - If rebase does not start, re-run comment: