Conversation
The first release run failed at startup, because the repository allows only four actions to run and the workflow introduced two more. A run that fails at startup cannot be re-run, and `main` takes no direct pushes, so the only way to retry was to merge another pull request purely to produce a push. Add `workflow_dispatch` so the workflow can be started from the Actions tab once whatever blocked it is fixed.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Adding `workflow_dispatch` in the previous commit opened a path it should not have. A manual run lets whoever starts it choose the branch, and both the workflow definition and the checked-out code then come from that branch, while npm's trusted publisher matches on repository and workflow filename rather than on ref. So anyone with write access could push a branch, dispatch it, and publish to the `latest` tag without review. That is a regression against the reason `main` requires a reviewed pull request in the first place. Gate both jobs on `github.ref == 'refs/heads/main'`, which leaves the manual trigger useful for retrying a run from `main` and closes the arbitrary-branch path. The check is repeated on the publish job rather than inherited: skipping release-please already skips it, but the job that holds `id-token` and can publish should not rely on another job's condition to stay on `main`.
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request is for: (mark with an "x")
examples/*modules/nextpackages/next-drupalstarters/basic-starterstarters/graphql-starterstarters/pages-starterGitHub Issue: n/a
Describe your changes
Adds
workflow_dispatchtorelease.ymlso it can be started by hand, and restricts the workflow tomainso that trigger cannot be abused.Why the manual trigger
The first run of the release workflow failed at startup. This repository allows only a few actions to run, and the workflow introduced two that were not on the list, so the run was rejected before any step executed. The allowlist has since been corrected.
The problem is retrying. A run that fails at startup cannot be re-run:
And the workflow's only trigger was a push to
main, which takes no direct pushes. So the sole way to retry was to merge another pull request purely to generate a push, which is what this one is.workflow_dispatchmeans that is not needed a second time.Why the ref check
workflow_dispatchon its own would have been a regression, so it does not ship alone.A manual run lets whoever starts it choose the branch. Both the workflow definition and the code
actions/checkoutfetches then come from that branch, and npm's trusted publisher matches on repository and workflow filename, not on ref. So anyone with write access could push a branch carrying a modifiedrelease.yml, dispatch it, and publish arbitrary code to thelatesttag without review.That defeats the reason
mainrequires a reviewed pull request. Both jobs are now gated ongithub.ref == 'refs/heads/main', which keeps the manual trigger useful for retrying a run frommainand closes the arbitrary-branch path.The check is repeated on the
publishjob rather than inherited. Skippingrelease-pleasealready skips it, because its output would be empty, but the job that holdsid-token: writeand can publish should not depend on another job's condition to stay onmain.What this does not change
Releases still originate from a merged release pull request. The dispatch trigger reruns the workflow; it does not create a release on its own, because
publishstill requiresreleases_created.Merging this produces the push that runs the release workflow, so it should also open the 2.1.0 release pull request.