Tools: New tag for plugin release not created successfully on svn

[mikachan]

Description

There is currently an issue with creating a new release tag (e.g. 16.8.0) on svn during the Gutenberg release process. Everything else in the workflow runs fine, and the plugin is successfully uploaded to the plugin directory, but the new tag isn't created.

I believe the issue happens during this workflow: Update Changelog and upload Gutenberg plugin to WordPress.org plugin repo.

Here is an example changeset which has manually created the tag: https://plugins.trac.wordpress.org/changeset/2978003/

cc. @ockham who has helped out many times with a manual fix post-release 🙇

Step-by-step reproduction instructions

I'm not sure how to test this as I've only ever seen it happen in production 😅

It happens when running the "Publish release" workflow as described here.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ockham]

FWIW, my workaround is as follows:

I have a locally checked out copy of https://plugins.svn.wordpress.org/gutenberg/trunk. All I’m doing is running svn up (to get the latest trunk), followed by this command (which needs 4 env vars set first: one is the plugin repo URL, one is the version we’re updating to, and the rest are the svn username and password.

[ockham]

Here's an (incomplete) list of some other instances of this issue that I've kept a record of:

• 16.0.0: GHA workflow, Slack convo
• 16.4.0: GHA workflow, Slack convo. The "Commit the content changes" step took 5m 8s.
• 16.5.0: GHA workflow, Slack convo. The "Commit the content changes" step took 6m 43s.
• 16.8.0: GHA workflow Slack convo. The "Commit the content changes" step took 11m 40s.

After merging #55261 (see), the error has consistently been svn: E160013: '/gutenberg/trunk' path not found:

• 16.9.0: GHA workflow Slack convo. The "Commit the content changes" step took 5m 44s.
• 17.0.0: GHA workflow. The "Commit the content changes" step took 5m 23s.
• 17.1.0: GHA workflow Slack convo. The "Commit the content changes" step took 5m 33s.
• 17.3.0: GHA workflow, Slack convo. The "Commit the content changes" step took 5m 36s.
• 17.4.0: GHA workflow. The "Commit the content changes" step took 5m 17s.
  • This time, the error was different:

     svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option
     svn: E215004: Commit failed (details follow):
     svn: E215004: No more credentials or we tried too many times.
     Authentication failed
     svn: E200042: Additional errors:
     svn: E120191: Error running context: The requested authentication type(s) are not supported
    

• The error doesn't seem to have occurred for 17.5.0-18.1.2 🎉
• 18.2.0: GHA workflow, Slack convo. The "Commit the content changes" step took 5m 40s.

[ockham]

Adding some more information from the 16.8.0 workflow:

[Sending all the files]
Sending        lib/load.php
Sending        readme.txt
Transmitting file data ..................................................................................................................................................................................................................................................................................................................................................................................................................done
Committing transaction...
svn: E175012: Commit failed (details follow):
svn: E175012: Connection timed out
Error: Process completed with exit code 1.

[ockham]

Googling the error code (E175012), I found this SO thread, which sounds kinda relevant:

When I commit files in svn I often get the situation where after it has transmitted all the files svn will hang and then eventually time out with the error svn: E175012: Connection timed out.

This seems to happen when I am uploading more than say 20 files.

I believe this is happening after all of the files have been transferred to the server as either new periods will have stopped being added after Transmitting file data in the console, or all of the files have been listed as sent in Tortoise. Also, if I then do an update from the repository I get merges for all of the files I've just tried to commit (or, more annoyingly, a ton of conflicts to resolve) and when I then go to commit again there is nothing to commit - presumably meaning all of the files were successfully transmitted the first time.

And the accepted answer:

Check whether any post-commit hook script is processing your commits.

This seems likely, as we know that e.g. Core runs some server-side post-commit checks.

Maybe we can increase the timeout (on the client side) to allow for those checks to finish running? 🤔

[ockham]

I added a 300s timeout to the svn commit command in #55621, just in time for the 16.9 release.
Unfortunately, tag creation failed once again; however, the error is different this time:

[Sending all the files]
Sending        packages/block-serialization-default-parser/class-wp-block-parser.php
Sending        readme.txt
Transmitting file data ...........................................................................................................................................................................done
Committing transaction...
svn: E160013: Commit failed (details follow):
svn: E160013: '/gutenberg/trunk' path not found
Error: Process completed with exit code 1.

So maybe the timeout did help; we might just need to tweak the workflow a bit more.

[madhusudhand]

Action failed while trying to release 17.3

[ockham]

We've merged #65591, which changes the workflow to transmit the updated trunk and new tag in a single commit. We've then tried this for the 19.9.0 release, which was successful (files in the plugins repo were updated, and the tag was created). The workflow did display an error at the end, though. Details are here.