Handle WP.org SVN missing tag warnings#79257
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
Updates the release workflow’s SVN-tag existence check so WP.org’s “missing tag” responses are correctly treated as exists=false, allowing the upload steps to proceed instead of failing early.
Changes:
- Expand the “missing tag” detection in
svn listerror output to includeW160013,E200009, andnon-existent(in addition toE160013). - Apply the same detection logic to both stable upload paths (trunk+tag and tag-only).
|
Flaky tests detected in 50ebd13. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27671783504
|
What?
Follow up to #78476
Updates the Gutenberg plugin upload workflow so a missing WordPress.org SVN tag is recognized when
svn listreportsW160013andE200009, not onlyE160013.Why?
During the Gutenberg 23.4.0 stable release, the workflow checked whether
tags/23.4.0already existed before committing to the plugin SVN repository. The tag did not exist, but WP.org SVN returned:The workflow only treated
E160013as "tag missing", so it failed before the release commit could run.How?
Both stable upload paths now treat
E160013,W160013,E200009, ornon-existentoutput fromsvn listasexists=false. Other SVN errors still print the error and fail the workflow.Testing Instructions
git diff --check.actionlintwas not installed locally, so I could not run full workflow linting.