So this wasn't quite what I had in mind when I suggested the approach. But it is clever and looks like it works! However, as we continue to add workflows that need to run prior to publishing a release, I think this could get repetitive and possibly make it easier to miss desired checks. The workflows that need this workflow_run event could also differ from repo to repo, which could make it hard to track.

The approach I was suggesting is detailed in the second option below. In an ideal world, the committing/opening a pull request would trigger the workflow runs on their own. But this would require more work to get set up. To trigger the builds automatically, here are two options.

Use repository_dispatch for committing/pushing.

The first option is to change the reusable-module-prep-release.yml workflow to only collect and prepare the needed information (new version, old version, latest tag date, etc.). At the end of that workflow, a repository_dispatch event could be triggered with that information passed. This would initiate another workflow that would perform the committing, pushing, and pull request creation steps.

repository_dispatch events have the access required to trigger builds as a result of push/pull_request events through the use of the $GITHUB_TOKEN.

One benefit of this approach is that the necessary npm (post-set-version|build|i18n) scripts, committing, pushing steps are extracted into a separate workflow. These are nearly identical in both the module and plugin preparation reusable workflows, so helps prevent repeating ourselves there.

Create a GitHub App for committing and pushing

In WP Core, we went this approach. It's similar to the first suggestion, but the difference is that it requires a GitHub App.

The second approach would also separate out the committing/pushing/PR creating logic out into a different workflow. But instead of a repository_dispatch event, that workflow would be triggered by a workflow_run event (for security purposes). That workflow would then generate a JWT (JavaScript Web Token) using the GH App's private key with the appropriate permissions and any commits/pushes would correctly trigger push/pull_request events.

Recommendation

I would be fine with the approach proposed here if we decide to come back to this. But since this is the first brand plugin that we're adding this to, it may be preferable to just figure this out now and go with one of the approaches above.

Yea, I think this might be the right direction. I don't think the repository_dispatch event would work, since it triggers the event in the default branch, but here we want it to run in the release branch.

I like the second option, and agree that we should come back to it when time allows. I think with a little tweaking we could also combine the module and plugin release prep workflows too, so we can consider doing all that once we have a github app created.

For now, I'll merge this in since it will allow us to get the testing and build for releases without having to manually run those workflows or closing and re-opening the release PR.