Code freeze does not prevent merging of PRs that previously passed CI

[rak-phillip]

This report is based of a recent instance where a PR was able to merge into a target branch that was actively under code freeze - #17403. The repro steps and actual behavior have not been verified and are based off discussions while discussing the code freeze behavior.

Steps to reproduce

1. Raise a PR against a release branch, ensure that it passes all CI gates
2. Update branches-metadata.json so that "codeFreeze": true is set for that branch
3. Attempt to merge the PR in the release branch

Actual behavior

All gates pass in this PR even though code freeze is in effect for the target branch.
The merge button is active, clicking the button merges the PR.

Expected behavior

Code freeze is in effect for the target branch and merging should be disabled for the PR in question.

Acceptance criteria

• When codeFreeze: true is set for a branch in branches-metadata.json, any open PR targeting that branch cannot be merged, regardless of whether its CI checks previously passed

Additional details

I think that there might be a gap between when a PR is raised and code freeze enforced that can allow a PR to be in a mergable state, even when code freeze is in place. It's almost as if we need the ability to run some checks when the merge button is clicked in github to assert that the code freeze is not in place before actually merging. Alternatively, the branch protection repo setting might be able to be programmatically enabled when making modifications to branches-metadata.json

[github-actions]

🎯 Agentic Issue Triage

Summary: The code freeze check in valid-pr.yaml only triggers on PR events (opened, edited, synchronize, milestoned, demilestoned). If a PR passes all CI gates before codeFreeze: true is committed to branches-metadata.json, no new event fires to re-run the check — leaving the merge button active and allowing the PR to merge despite the freeze.

📋 Root Cause Analysis

The relevant workflow is .github/workflows/valid-pr.yaml which calls .github/workflows/scripts/pr-check-milestone.sh. The script reads branches-metadata.json from the default branch and exits with failure if codeFreeze == true. However:

• The workflow trigger is pull_request: types: [opened, edited, synchronize, milestoned, demilestoned]
• When branches-metadata.json is updated on the default/target branch to set codeFreeze: true, no PR event is fired for existing open PRs
• GitHub treats previously-passing required status checks as still passing, so the merge button remains enabled

This is a classic TOCTOU (time-of-check / time-of-use) gap: the check ran at PR open/update time, not at merge time.

🔍 Possible Solutions

Option A – GitHub Actions: push event on branches-metadata.json triggers a re-check
When branches-metadata.json is pushed to the default branch, trigger a workflow that iterates over all open PRs targeting frozen branches and re-requests the validate-branch-milestone check. This causes GitHub to invalidate the existing status, blocking merge.

Option B – Branch Protection Rules (programmatic)
When codeFreeze is set to true in branches-metadata.json, a companion workflow automatically enables stricter GitHub branch protection rules for that branch (e.g., requiring a new required status check that no PR has passed). This is the approach hinted at in the issue description.

Option C – GitHub Rulesets with a dynamic required check
Add a GitHub Ruleset (repo settings) that requires a status check that is re-evaluated on push to the base branch. GitHub's "required status checks" can be configured to require re-run when the base branch changes, but today only pushes to the PR branch trigger re-evaluation.

Option D – Merge Queue
Enable GitHub's merge queue for frozen branches. The queue runs checks at merge time against the latest base, allowing the code-freeze check to fire again.

🛠️ Recommended Approach

The lowest-friction fix is likely Option A:

1. Add a new workflow triggered on push to the default branch when branches-metadata.json changes:

   on:
     push:
       branches: [master]
       paths:
         - 'branches-metadata.json'

2. In the workflow, use the GitHub API to find all open PRs targeting branches that now have codeFreeze: true
3. For each such PR, use POST /repos/{owner}/{repo}/statuses (or re-request check runs) to mark the Branch Milestone check as failure — this blocks the merge button immediately

Alternatively, consider enabling branch protection for frozen branches programmatically within the same workflow using the GitHub API.

🔗 Relevant Files & Links

• .github/workflows/valid-pr.yaml — The PR validation workflow (trigger is the gap)
• .github/workflows/scripts/pr-check-milestone.sh — The code freeze check logic
• branches-metadata.json — Source of truth for code freeze state
• Related PR: [backport 2.14.2] fixed release notes test and flakiness caused by test isolation #17403 — the real-world incident that prompted this issue
• GitHub Docs: Re-running required status checks
• GitHub Docs: Merge Queue

✅ Sub-tasks Checklist

• Confirm the exact sequence that allowed [backport 2.14.2] fixed release notes test and flakiness caused by test isolation #17403 to merge during freeze (verify repro)
• Decide on the fix strategy (re-trigger checks vs. branch protection API vs. merge queue)
• Implement a workflow that detects codeFreeze changes in branches-metadata.json and invalidates open PR checks on frozen branches
• OR: implement programmatic branch protection toggling when freeze is activated
• Add documentation / CONTRIBUTING notes about how to activate/deactivate code freeze
• Test the fix by simulating the scenario (freeze a branch, open a PR, pass CI, then verify the PR cannot merge)

Generated by Agentic Triage for issue #17770 · ● 543.1K · ◷

[github-actions]

🤖 Issue grooming questions

The problem description, steps to reproduce, and actual vs. expected behavior are clear. One item is needed before this can be triaged for development.

Missing: Acceptance Criteria

Please add a concrete, testable checklist defining what "fixed" looks like. For example:

• When codeFreeze: true is set for a branch in branches-metadata.json, any open PR targeting that branch cannot be merged, regardless of whether its CI checks previously passed.
• If a PR's CI checks passed before code freeze was enabled, the merge button is blocked once code freeze takes effect.
• A gate or check is enforced at merge time (not only at CI execution time), so a PR cannot slip through during an active code freeze.

This comment was generated automatically to help gather the information needed to groom this issue.

Generated by Daily Issue Grooming · ● 870.5K · ◷

[github-actions]

🤖 Issue grooming analysis

Great update — the issue body has been improved since the last review and now satisfies all four primary grooming criteria.

✅ Clear Problem Statement
The title and description clearly explain the TOCTOU gap: a PR that passed CI before codeFreeze: true was set retains an active merge button because no new CI event is fired on existing open PRs when branches-metadata.json is updated. The real-world incident (#17403) provides concrete context.

✅ Acceptance Criteria
The issue now includes a testable acceptance criterion:

• When codeFreeze: true is set for a branch in branches-metadata.json, any open PR targeting that branch cannot be merged, regardless of whether its CI checks previously passed.

✅ Technical Details
The relevant mechanism is identified — branches-metadata.json, the valid-pr.yaml workflow, and the gap in re-triggering checks on existing PRs. Potential solution approaches (re-triggering checks, programmatic branch protection) are noted.

✅ Reproducibility
Numbered steps to reproduce are provided along with explicit expected vs. actual behaviour and the precondition that all CI gates pass before the freeze is set.

This analysis was generated automatically based on the repository's grooming checklist.

Generated by Daily Issue Grooming · ● 972.7K · ◷