Release: Verify SVN deployment after publication - #82513
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. To trigger a review, include ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
🤖 PR meta 🤖⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
|
Closes #55295. Closes #79804. Related: #79919.
What?
Verify the complete SVN deployment before reporting a release as successful, including when SVN reports a publish error or the release tag already exists.
Why?
The 23.9.0 upload failed with
E160013: '/gutenberg' path not foundafter SVN had committed both trunk and the tag in revision3678189. All 2,181 files match the release ZIP after applying the workflow's stable-tag substitution and changelog artifact. This matches the failure pattern reported in both issues; the underlying SVN server or network cause remains unconfirmed.How?
Share the publication logic between trunk and tag-only uploads. After publication, export each required path at the same SVN revision and compare all paths and file contents against the prepared release. Retry verification for up to 15 minutes, with a fresh revision per attempt and bounded SVN reads.
Only a complete match succeeds. Missing, different, or unreadable content remains a failure. Existing tags receive the same verification, and uncertain writes are never repeated automatically. The verified revision appears in the logs and job summary.
This retains the atomic trunk-and-tag commit. #79919 separately proposes changing the upload strategy. Verification covers SVN contents; WordPress.org ZIP generation and distribution can finish later.
Testing Instructions
Run
bash tools/release/test/publish-to-svn.shon Linux with Subversion and GNU diff/timeout installed. The tests use disposable local SVN repositories and need no WordPress.org credentials.They cover successful publication, a committed transaction followed by a simulated failed response, identical existing releases, missing or different files despite matching version headers, failed and stalled reads, delayed content visibility, tag-only releases, and concurrent changes that must not produce a match across different revisions. The new CI job runs this suite.
Validation
3678189against the release ZIP and original workflow changelog artifact.Use of AI Tools
Codex investigated the failure, implemented the change, and ran the verification described above.