Fix GitHub Actions Workflow Dispatch Errors
Resumen
Pixel’s announcement explains why GitHub Actions may reject a manual workflow dispatch even when the workflow appears on the default branch. It covers two causes: the selected branch or tag predates the workflow, or its version lacks the workflow_dispatch trigger—and clarifies how the default branch and selected ref affect dispatch.
DEV Community
Workflow does not have a workflow_dispatch trigger in this branch
Workflow does not have a workflow_dispatch trigger names the branch or tag you selected, and that is the whole diagnosis: the file is read at the ref you dispatched, not at the ref you are working on. Merging to the default branch fixes a different problem, which is why people who have already done that meet this message and conclude the rule is broken. Two rules, applied at two moments. The default branch decides whether the workflow is offered; the selected ref decides whether the dispatch is accepted. What this error means You pick a workflow, choose a ref, press the button or call the API, and the dispatch is refused with a sentence that names the branch or the tag. The workflow is listed, so it clearly exists. It ran last week on the default branch, so the trigger clearly exists too. The thing that changed is the ref, and the part of the message that does the work is its last two words. Dispatching an old release tag is the version of this that catches the most people, because a tag cut before the workflow was written obviously does not contain it, and nothing about the dispatch dialog hints that the tag is where the file will be read from. ```Dispatch refusal, quoted from age533174851-sudo/auto-platform#248; a tag variant ends "in this tag" Workflow does not exist or does not have a workflow_dispatch trigger in this branch
Common causes
The selected ref is an old tag cut before the workflow existed
The most frequent shape by a wide margin. The workflow is on the default branch, the tag is older than the workflow, and the dispatch is aimed at the tag because the tag is the code you want.
The file exists at the ref but without the manual trigger
The copy at that ref is an earlier version whose on block has push and pull request but not workflow_dispatch. The message covers this case explicitly, which is why it offers two possibilities rather than one.
The ref was never merged and the dispatch targets it directly
A workflow developed on a feature branch and dispatched at that branch fails the first rule rather than this one, because nothing is listed. If you reached a dispatch at all, the workflow is registered and the ref is the problem.
A script sends a ref that differs from the one intended
Dispatches made from other automation frequently build the ref from a variable. A tag name where a branch was meant, or an empty value falling back to a default, produces a refusal that looks like a permissions problem until you print the ref.
How to fix it
Confirm what is at the ref before editing anything
- Ask the API for the workflow file at that exact ref.
- If the call returns nothing, the file is absent at that ref and no workflow change will help.
- If it returns the file, read its
onblock at that ref and look for the manual trigger.
```shell
gh api repos/OWNER/REPO/contents/.github/workflows/publish.yml?ref=v1.2.0
Pass the ref as an input instead of dispatching at it Keep the workflow on the default branch, take the tag or commit as a workflow_dispatch input, and check that out in the job. The workflow you maintain then runs against the code you want, and older refs stop mattering. - uses: actions/checkout@v5
with:
ref: ${{ inputs.release_tag }}
fetch-depth: 0
Add the trigger at the ref if the ref is a live branch For a long lived release branch rather than a fixed tag, cherry pick the workflow change onto that branch. This is a real fix for a branch you will dispatch repeatedly, and useless for a tag, which should not be rewritten. Print the ref your automation is sending Where the dispatch comes from another workflow or a script, log the ref immediately before the call. A refusal that names a ref you did not expect to see turns a confusing permissions hunt into a one line fix. echo "dispatching at ref: $REF"
gh workflow run publish.yml --ref "$REF"
How to prevent it Treat the ref in a dispatch as the source of the workflow definition, not only of the code...

Powered by Readybot.io