Combine the release steps to ensure that releases are tagged

[dd32]

See #55295

What?

Why?

How?

Currently the release process is timing out. This is due to the 5 minute timeout included in the trunk commit command.

Additionally; The current steps appear to be attempting to set the Stable Tag to the current stable (not the current release) but is setting it to the upcoming release anyway. This was broken in 68fa80a.

Ultimately, this process can be simplified by combining the Stable Tag / Trunk Commit / SVN copy into a single commit.
This will avoid situations where the trunk commit passes but the tag is not created.

Raising the timeout to 10 minutes (which is the default in SVN) should also hopefully resolve the timeout issues run into during the process.
Increasing it to 15 or 20 minutes to be on the safe side would also not be out of the question.
However is not strictly needed, as since this is now the last command in the action as long as the timeout is due to the post-commit server-side scripts taking a while, this should not cause any issue, as the commits are succeessful.

The main benefit that increasing the timeout provides is that the action on GitHub will appear to have succeeded where currently it fails.

Testing Instructions

I have not actually tested this yet, and while the commands appear correct, additional care should be taken prior to merging.

Testing Instructions for Keyboard

N/A

Screenshots or screencast

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dd32 <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: mikachan <[email protected]>
Co-authored-by: ockham <[email protected]>
Co-authored-by: talldan <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[andrewserong]

The GB 19.3 release steps just timeout out and had to be restarted, so this PR sounds like a great solution to me! My knowledge of svn is very basic, so I'm not sure I'm the best person to review, but the changes all look logical 👍

For the Github Actions to pass, I think this PR might need a rebase as there've been at least one or two PRs recently to ensure GB is compatible with recent commits in wordpress-develop.

[mikachan]

I also don't have much knowledge of SVN, but I've experienced this timeout issue multiple times, and I agree with @andrewserong that this sounds like a good solution and is certainly worth a try.

I know @ockham has looked into this a lot, so might be in one of the best positions to review this 🙇

[ockham]

Hey @dd32, thanks a lot for working on this, it's been a long-standing headache.

It'd be great if we could test it before landing the PR. This is possible, but a bit complicated. I've covered it e.g. in the PR description of #27591, where I first added this workflow. Essentially, you need a dummy svn repo (which I created at https://riouxsvn.com/), and a personal fork of the Gutenberg repo in GH. You can then push the contents of this branch to your fork's trunk, change the PLUGIN_REPO_URL var in the workflow file, and set the svn_username and svn_password secrets in your fork to your riouxsvn.com account's. This will allow you to trigger the workflow from your fork. (This is explained in more detail in #27591, though.)

I'm happy to add you (or anyone else who'd like to test this) to the dummy repo I created. I probably won't be able to test this myself this week, but if no one else gets around to doing so, I can cycle back to this next week.

[ockham]

I was kinda curious and gave it a try on my fork: https://github.com/ockham/gutenberg/actions/runs/11142232378/job/30964762470

It's still running but looking good so far. We should probably double-check a few things once it's completed (e.g. has the tag been created, has the version been updated in trunk's readme.txt, etc).

[talldan]

@ockham Were you able to verify that it works ok?

[ockham]

@talldan Apologies for dropping the ball on this! The workflow ended up failing with

Committing transaction...
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:

****[RiouxSVN Notice]****
The maximum size of your repository 'gutenberg-test', which is 50 MB, would have been exceeded. You can get more storage by upgrading your repository.
Error: Process completed with exit code 1.

Which is of course unrelated. Before that happended, it was preparing the file changes for committing, so that looked kind of good:

Shall we give it a try and merge the PR? Worst case, it fails next time we try to publish a release, in which case we can simply revert.

[talldan]

Shall we give it a try and merge the PR? Worst case, it fails next time we try to publish a release, in which case we can simply revert.

It might be good to line it up with when someone who's comfortable troubleshooting is doing the release. I'm not sure who's handling the current or next releases.

[ockham]

Shall we give it a try and merge the PR? Worst case, it fails next time we try to publish a release, in which case we can simply revert.

It might be good to line it up with when someone who's comfortable troubleshooting is doing the release. I'm not sure who's handling the current or next releases.

Good idea. I think @priethor coordinates the releases.

👋 Héctor, do we have someone lined up who should be comfortable troubleshooting if there's an issue with this change?

[ockham]

@ramonjd is in charge of GB 19.9, and has kindly agreed to taking part in this experiment 😬

I'll thus merge this PR and will backport it to the 19.9 branch. I'll make sure to start my workday early on Wednesday so I can help out if anything goes wrong during the release process.

[ockham]

Let's give this a try 👍

[ockham]

Cherry-picked to release/19.9 branch in 2e34bed.

[ramonjd]

Thanks @ockham !

[ockham]

@ramonjd just released 19.9.0. The workflow seems to have worked fine, with both svn trunk being updated, and the 19.9.0 tag being created; the plugin repo reflects the latest version, which I installed and smoke-tested on a test site.

The workflow did throw an error at the end, though:

Transmitting file data ........................................................................................................................................................................................................................................................................................................................................................................................................done
Committing transaction...
svn: E160013: Commit failed (details follow):
svn: E160013: '/gutenberg' path not found
Error: Process completed with exit code 1.

Since the release seems to have been successful, there's probably no further action needed. In the long run, it'd be nice to get rid of the error -- maybe it's still due to a post-commit hook that's running on the server side (see).

@dd32 Maybe you're just the right person to ask if there is something on the server side that could cause this?

(If there really is such a hook that e.g. performs some checks on files, it becomes more likely to time out if the number (and size) of files transmitted in a commit is larger. Ironically, by transmitting trunk and the new tag at once, this PR increased the number of files in the commit 😅 )