Release Workflow: Install Subversion

[Mamaduka]

What?

Adds step to install manually svn for plugin release workflow.

Why?

The latest GitHub action runners remove svn. See actions/runner-images#9848.

Testing Instructions

[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: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: joemcgill <joemcgill@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>

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

[joemcgill]

Just a few questions, but looks like the right idea

[joemcgill]

This is probably good assuming svn doesn't get added back to these boxes, otherwise it will be a little wasteful.

Are there any circumstances where the upload-tag job is run below without first running the upload job? If so, this should be handled in it's own job.

[Mamaduka]

From what I can see in the workflow, upload-tag might run for minor release and changelog updates.

This means we should also add the svn installation step to the upload-tag job, correct?

[joemcgill]

Ah, I see. Both run in github.event.release.assets[0] is truthy, but which one depends on whether needs.compute-should-update-trunk.outputs.should_update_trunk is true or not.

Perhaps it's better to add a job prior to these two that run if: github.event.release.assets[0] assuming both jobs run on the same environment. @desrosj what would you recommend?

[desrosj]

Perhaps it's better to add a job prior to these two that run if: github.event.release.assets[0] assuming both jobs run on the same environment. @desrosj what would you recommend?

Do you mean have a separate job before upload and upload-tag that installs SVN? If so, that unfortunately does not work. Each job is run on a separate, fresh runner machine. So we would need to add the step above to both of those jobs.

[Mamaduka]

Updated in 04089c5.

[github-actions]

Flaky tests detected in be92551.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12913194514
📝 Reported issues:

• [Flaky Test] should show the original content after revert and page reload #68604 in /test/e2e/specs/site-editor/template-revert.spec.js

[Mamaduka]

If I'm not mistaken, cherry-picking this fix into the release branch, should re-trigger the plugin release job with the latest workflow?

Update: Let me try to reiterate the question 😄

Is there a way to re-run an action (triggered by a release) but point the workflow file to a more recent SHA? After I've cherry-picked this fix.

[desrosj]

Is there a way to re-run an action (triggered by a release) but point the workflow file to a more recent SHA? After I've cherry-picked this fix.

Without updating the workflow to handle this, I don't think so. The path here would need to be to add the workflow_dispatch event to support manually rerunning the workflow through the UI, and the addition of an input for a specific tag or SHA value. The entire workflow would then need to be updated to perform tasks in that context instead of how it's set up now. That may be really difficult for things like updating the changelog. But not sure.

[desrosj]

This should do the trick of fixing the error. But doesn't help us with the missed version that we're discussing in Slack. I say let's give this a try for the next release.