From 7ede1ec4b04e2b41519e09f0cc7b760ca28ec34c Mon Sep 17 00:00:00 2001 From: diegosouzapw Date: Tue, 7 Apr 2026 18:34:43 -0300 Subject: [PATCH] workflow: merge PRs into release branch instead of main - Added Step 3.5 to redirect PR base branches from main to release/vX.Y.Z - Updated merge commands to target release branch - Replaced close-PR step with sync-local-branch step - Added test coverage verification in finalization step - Ensures all changes accumulate in release branch before final merge to main --- .agents/workflows/review-prs.md | 60 +++++++++++++++++++++++++++------ 1 file changed, 49 insertions(+), 11 deletions(-) diff --git a/.agents/workflows/review-prs.md b/.agents/workflows/review-prs.md index 1f474b5a..ae8fcbc0 100644 --- a/.agents/workflows/review-prs.md +++ b/.agents/workflows/review-prs.md @@ -8,7 +8,7 @@ description: Analyze open Pull Requests from the project's GitHub repository, ge This workflow fetches all open PRs from the project's GitHub repository, performs a critical analysis of each one, generates a detailed report, and waits for user approval before proceeding with implementation. **All improvements are committed on the current release branch** (`release/vX.Y.Z`). -> **BRANCH RULE**: All work MUST happen on the current `release/vX.Y.Z` branch. Never create separate feature or fix branches. If no release branch exists yet, create one first using `/generate-release` Phase 1 steps 1–5. +> **BRANCH RULE**: PRs are ALWAYS merged into the current `release/vX.Y.Z` branch, NEVER directly into `main`. The release branch acts as a staging area — only after all PRs are integrated and tests pass does the release branch get merged into `main` via the `/generate-release` workflow. ## Steps @@ -53,7 +53,7 @@ If already on a `release/vX.Y.Z` branch, continue working there. **Step 3b — Fetch full metadata for each PR** (one call per PR): - For each PR number from step 3a, run: - `gh pr view --repo / --json number,title,author,headRefName,body,createdAt,additions,deletions,files` + `gh pr view --repo / --json number,title,author,headRefName,baseRefName,body,createdAt,additions,deletions,files` - You may batch these into parallel calls (up to 4 at a time). **Step 3c — Fetch diffs for each PR** (one call per PR, saved to /tmp): @@ -70,6 +70,29 @@ If already on a `release/vX.Y.Z` branch, continue working there. **Verification**: Confirm the count of PRs analyzed matches the count from step 3a before proceeding. +### 3.5 Redirect PR Base Branches to Release Branch + +// turbo-all + +**⚠️ CRITICAL**: Contributors typically open PRs targeting `main`. Before analyzing or merging, redirect ALL open PRs to target the current release branch instead. + +```bash +# Get the current release branch name +RELEASE_BRANCH=$(git branch --show-current) # e.g. release/v3.5.4 + +# For each open PR that targets main, change its base to the release branch +for PR_NUM in $(gh pr list --repo / --state open --json number,baseRefName --jq '.[] | select(.baseRefName == "main") | .number'); do + echo "Redirecting PR #$PR_NUM → $RELEASE_BRANCH" + gh pr edit "$PR_NUM" --repo / --base "$RELEASE_BRANCH" +done +``` + +This ensures: +1. PRs merge into the release branch, not directly into `main` +2. Merge conflict detection is accurate against the release branch +3. The release branch accumulates all changes before the final merge to `main` +4. If the release branch doesn't exist on remote yet, push it first: `git push origin $RELEASE_BRANCH` + ### 4. Analyze Each PR — For each open PR, perform the following analysis: #### 4a. Feature Assessment @@ -141,7 +164,7 @@ Perform a **global impact assessment** to verify whether the PR changes are comp > **⚠️ Fixes should be pushed back to the PR branch before merging.** We want the PR itself to be green and fully valid before it integrates. -- **Sync latest fixes:** Merge `main` or the current `release` branch into the PR branch so the PR inherits any latest CI or integration test fixes (preventing false-positive failures). +- **Sync latest fixes:** Merge the current `release` branch into the PR branch so the PR inherits any latest CI or integration test fixes (preventing false-positive failures). - **Implement improvements:** Apply the required fixes identified in the analysis directly on the PR branch (e.g., adding missing API routes, fixing SSRF, applying comments from other agents). - **Pushing changes to PR branches:** @@ -167,12 +190,19 @@ Perform a **global impact assessment** to verify whether the PR changes are comp // turbo - Run: `npm test` or equivalent test command -### 8. Merge & Integrate +### 8. Merge into Release Branch -- Once the PR is green (you can check with `gh pr status`), proceed to merge the PR into the current release branch (`release/vX.Y.Z`). +> **⚠️ IMPORTANT**: PRs are merged into the **release branch** (`release/vX.Y.Z`), NOT into `main`. + +- Once the PR is green (you can check with `gh pr status`), merge the PR into the release branch. +- The PR's base was already changed to the release branch in step 3.5, so the default merge target is correct. ```bash - gh pr merge --repo / + # Merge the PR (base is already set to release/vX.Y.Z from step 3.5) + gh pr merge --repo / --squash --body "Integrated into release/vX.Y.Z" + + # If the PR is a draft, mark it as ready first + gh pr ready --repo / ``` - Post a **thank-you comment** on the PR via the GitHub API @@ -183,12 +213,14 @@ Perform a **global impact assessment** to verify whether the PR changes are comp - Be friendly, professional, and encouraging - Example: _"Thanks @author for this great contribution! 🎉 The [feature/fix] has been integrated into the release/vX.Y.Z branch and will be part of the next release. We appreciate your effort!"_ -### 9. Close the Original PR +### 9. Sync Local Release Branch -- Close the original PR with a comment explaining it was integrated into the release branch: - ```bash - gh pr close --repo / --comment "Integrated into release/vX.Y.Z. Will be released as part of v3.X.Y. Thank you!" - ``` +After merging PRs, sync the local release branch to include the new changes: + +```bash +git fetch origin +git pull origin release/vX.Y.Z +``` ### 10. Continue or Finalize @@ -196,4 +228,10 @@ After processing all approved PRs: - If more PRs remain, go back to step 7 - When all PRs are processed, **update CHANGELOG.md** on the release branch with all new entries +- Run **test coverage** to verify all metrics stay above 85%: + ```bash + npm run test:coverage + ``` +- Fix any test regressions introduced by merged PRs - Run `/generate-release` workflow Phase 1 steps 7–10 (tests → commit → push → open PR to main → wait for user) +- The `/generate-release` workflow handles the final merge from `release/vX.Y.Z` → `main`