Fix GitHub Actions Reusable Workflow Not Found

DEV Community

GitHub Actions reusable workflow was not found

GitHub Actions reusable workflow was not found means the uses: reference was well formed but resolved to nothing: the file is not directly under .github/workflows at that ref, the ref does not exist on the target repository, or the caller is not allowed to read it. The annotation prints every hop as a chain of arrows, so check the entry after the last arrow first; on a nested call it is often a reference inside a workflow you did not write. Four checks in order: the path exists, the ref exists, the caller may read it, and the file declares that it can be called. The chain stops at the first failure. What this error means The run is created and then ends immediately, with no jobs and no logs. In the Actions tab it carries an annotation titled with the caller file and a line number, and the body is a chain of quoted references joined by arrows, ending in a colon and the words that give this page its name. Because nothing ran, there is no step to open and any tooling looking for a failed job finds none. The chain is the diagnosis: each arrow is one hop the resolver made, so the reference on the last line is the one that could not be loaded. On a nested call that line is often a workflow you did not write the reference for. ```Invalid workflow file annotation, quoted from wazuh/wazuh-dashboard-plugins#9158 error parsing called workflow ".github/workflows/4_builderpackage_dashboard.yml" -> "wazuh/wazuh-security-dashboards-plugin/.github/workflows/[email protected]" (source tag with sha:e9267cedfeaf707032ac9454ce494a32745585a3) --> "./.github/workflows/4_builderprecompiled_base-dev-environment.yml" : workflow was not found. See https://docs.github.com/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows

Common causes

The path or the file name is wrong

The ordinary case. A called workflow must sit directly in the workflows directory, so a file moved into a subdirectory stops resolving, and so does an extension that is .yaml on one side and .yml on the other. The message names the file it looked for.

The ref does not exist on the target repository

Refs are resolved on the repository that owns the called workflow, not on yours. A release that tags several repositories at once is the usual source: the tag exists where you are standing but not where you are calling.

The called workflow does not declare workflow_call

The file is found and still refused, because nothing marks it as callable. This one has its own wording, about a missing trigger rather than a missing workflow, and it is common when a manually run workflow gets reused.

The caller cannot read the target repository

A private or internal repository has to allow its workflows to be used elsewhere, and the setting lives on the target rather than on the caller. Nothing about the reference looks wrong, which is why the error links the access documentation.

The failing reference is one level down

Resolution recurses, so a workflow you call may call others, and a relative reference inside it resolves against its own repository and commit. The chain is the only place that distinction is visible.

How to fix it

Read the chain from the bottom up

1. Find the entry after the last arrow: that is the reference that failed.
2. Note which repository it belongs to, which is the repository of the entry above it for a relative reference.
3. Check the path, then the ref, then the access, in that order, against that repository.

Confirm the file and the ref from the API

One call tells you whether the file exists at that ref on that repository, answering the path and ref questions together.

```Terminal (illustrative)
$ gh api repos/octo-org/shared/contents/.github/workflows/package.yml?ref=v2 --jq .name
$ gh api repos/octo-org/shared/git/ref/tags/v2 --jq .object
Make the called workflow callable A workflow becomes reusable by declaring the trigger, and it can carry several at once. Ke...

Powered by Readybot.io