Problem description
When a release snapshot is active (a release-snapshot/* branch exists), release-plan.yaml should be frozen. Currently, the PR validation workflow (pr_validation.yml) does not check for this condition, so PRs that modify release-plan.yaml can be merged even while a snapshot is in progress.
This creates a configuration drift scenario: the release snapshot was created from specific release-plan.yaml settings (target tag, type, APIs), but the merged change may have altered those settings. The release then proceeds with outdated configuration.
Possible evolution
Add a check to pr_validation.yml that detects when a release-snapshot/* branch exists and blocks PRs that change release-plan.yaml:
- After the existing exclusivity check, use the GitHub API to list branches matching
release-snapshot/*
- If any exist and the PR modifies
release-plan.yaml, fail with a clear error explaining:
- A release snapshot is active and
release-plan.yaml changes are frozen
- To proceed: discard the snapshot first (
/discard-snapshot <reason> on the Release Issue), then merge the PR and create a new snapshot
- Or wait until the current release is published
- The commit status check provides visibility in the PR Files tab
This is a preventive complement to the post-merge config drift warning in the release automation workflow.
Alternative solution
Rely solely on the post-merge config drift warning (informational comment on the Release Issue after release-plan.yaml changes land on main). This is less strict but already implemented in the release automation workflow.
Additional context
- This enhancement can be implemented on
v0 independently from the full release automation workflow
- The existing
pr_validation.yml already has the release-plan.yaml change detection (tj-actions/changed-files) and exclusivity check — this adds a new condition using the same detection
- Related: the CAMARA release detailed design defines a "scoped configuration freeze" (G2) that locks
release-plan.yaml while a snapshot is active
Problem description
When a release snapshot is active (a
release-snapshot/*branch exists),release-plan.yamlshould be frozen. Currently, the PR validation workflow (pr_validation.yml) does not check for this condition, so PRs that modifyrelease-plan.yamlcan be merged even while a snapshot is in progress.This creates a configuration drift scenario: the release snapshot was created from specific
release-plan.yamlsettings (target tag, type, APIs), but the merged change may have altered those settings. The release then proceeds with outdated configuration.Possible evolution
Add a check to
pr_validation.ymlthat detects when arelease-snapshot/*branch exists and blocks PRs that changerelease-plan.yaml:release-snapshot/*release-plan.yaml, fail with a clear error explaining:release-plan.yamlchanges are frozen/discard-snapshot <reason>on the Release Issue), then merge the PR and create a new snapshotThis is a preventive complement to the post-merge config drift warning in the release automation workflow.
Alternative solution
Rely solely on the post-merge config drift warning (informational comment on the Release Issue after
release-plan.yamlchanges land on main). This is less strict but already implemented in the release automation workflow.Additional context
v0independently from the full release automation workflowpr_validation.ymlalready has therelease-plan.yamlchange detection (tj-actions/changed-files) and exclusivity check — this adds a new condition using the same detectionrelease-plan.yamlwhile a snapshot is active