Workflows: Re-enable manually triggered workflows on forks #32821
Conversation
ockham
changed the title
Most of these job are only run manually anyway, so we shouldn't need to prohibit them from running on forks. Furthermore, these checks make it much harder to test changes to this workflow on a fork. See #32114 (comment)
ockham
force-pushed
the
update/build-workflow-reenable-manual-trigger-on-forks
branch
from
77100e7
to
244bd02
Compare
There was a problem hiding this comment.
It seems like with the other recent changes made elsewhere, the first job in this workflow will always run regardless of where the run is being requested. I think we'll need to revise this a bit to account for that.
I think that compute-stable-branch could check for the WordPress/Gutenberg repository. I don't know if there's any benefit for allowing this to run on forks.
Thanks @desrosj, good spot -- I forgot about the newly added step when rebasing 😅
It's required for the manually triggered workflow (to select the release branches from which we allow publishing a release, per #32560). For that reason, I'd like to be able to run it on forks also -- otherwise, we won't be able to test this workflow on forks once again 😅 I'll guard with a |
|
|
@desrosj Would you mind giving this another quick look? 😊 🙏 |
Thank you! 🎉
Yep! 👍
We were considering that kind of flow at some point, but decided for the current flow instead: The release is triggered manually, the workflow creates the version bump commit, builds the plugin, and attaches it as an asset to a release draft. The tag is only created by GH once the release is published. (That's more of a GH feature than a GH Actions one; it's possible to specify a tag that doesn't exist yet in a release draft, and GH will happily create it for the given ref when the release is published). |
* Remove repository checks Most of these job are only run manually anyway, so we shouldn't need to prohibit them from running on forks. Furthermore, these checks make it much harder to test changes to this workflow on a fork. See #32114 (comment) * Run build job only on manual trigger, or on gutenberg repo * Only run compute-stable-branches branch if triggered manually (cherry picked from 2f09068)
* Remove repository checks Most of these job are only run manually anyway, so we shouldn't need to prohibit them from running on forks. Furthermore, these checks make it much harder to test changes to this workflow on a fork. See #32114 (comment) * Run build job only on manual trigger, or on gutenberg repo * Only run compute-stable-branches branch if triggered manually
Description
Re-enable manually triggered workflows on forks, to allow for better testability of changes to those workflows.
See #32114 (comment) for background.
How has this been tested?
Fork GB, and try to trigger release creation on your fork (using this branch). It's what I did to test #32560, so see the links to GHA workflows on my fork under the "How has this been tested?" section of that PR 😬