GitHub Actions errors and fixes

Indentation is wrong: a key is not lined up with its siblings, or sits under the wrong parent. YAML uses indentation for structure, so the parser meets a key where it expects something else and stops.

Check

actionlint .github/workflows/ci.yml   # names the line and column of the bad key
python3 -c "import yaml,sys; yaml.safe_load(open(sys.argv[1]))" .github/workflows/ci.yml   # needs PyYAML; 'did not find expected key' or 'mapping values are not allowed' means indentation

Fix

Line the key up with its siblings using spaces, the same number per level as the rest of the file.

A tab is used for indentation. YAML does not allow tabs there, so the parser fails with found character that cannot start any token.

Check

grep -nP '\t' .github/workflows/ci.yml   # any line printed holds a tab

Fix

Replace the tabs with spaces, and set your editor to insert spaces in YAML files.

A value contains : or starts with a character YAML treats as syntax (*, &, !, @, a backtick, { or [). The parser reads it as a new key or a tag instead of plain text.

Check

sed -n '<line-1>,<line>p' .github/workflows/ci.yml   # the reported line and the one above: an unquoted value with ': ' or a leading * & ! @ { [

Fix

Quote the value, or move a long command into a run: | block.

A required key is missing, such as runs-on or steps in a job. The schema needs it, so GitHub reports Required property is missing: <key>.

Check

gh run view <run-id>   # the annotation repeats the line, column and missing key
actionlint .github/workflows/ci.yml   # reports the same key locally

Fix

Add the key in the job the line points to, for example runs-on: ubuntu-latest.

A key is misspelt or indented under the wrong parent (stepz:, or with: under the job instead of the step). The schema does not allow it there, so GitHub says Unexpected value '<key>'.

Check

actionlint .github/workflows/ci.yml   # 'unexpected key' lists the keys allowed there

Fix

Fix the spelling, or move the key under the right parent.

A value is not allowed: an unknown permission name, or uses: without @ref. The schema checks values too, so the message points at that line.

Check

sed -n '<line>p' .github/workflows/ci.yml   # the key and value at the reported line

Fix

Use a valid permission name (contents, pull-requests, id-token, ...) and give every uses: a ref (owner/repo@<sha or tag>).

A branches, tags or paths filter excludes the event: branches: [master] when the branch is main, paths that do not match the changed files, or a tag pushed to a branches-only trigger. GitHub checks filters before creating a run, so nothing appears.

Check

gh workflow view ci.yml --yaml | grep -n -A8 '^on:'   # compare the filters with the branch, tag and files you pushed
git diff --name-only HEAD~1   # does any changed file match the paths filter?
gh run list --workflow ci.yml --limit 5   # the last runs, and on which events

Fix

Match the filters to the real branch names and layout, and add tags: for tag pushes.

The workflow or Actions is turned off: disabled by hand, a schedule disabled after 60 days without activity in a public repository, Actions disabled for the repository, or a fork where Actions was never enabled. A disabled workflow creates no runs.

Check

gh workflow list --all   # state disabled_manually or disabled_inactivity: the workflow is off
gh api repos/<owner>/<repo>/actions/permissions --jq .enabled   # false: Actions is off for the repository

Fix

Turn it back on: gh workflow enable ci.yml, or Settings > Actions > General for the repository or the fork.

GitHub skips the event by rule: a commit message with [skip ci], a pull request with a merge conflict (pull_request workflows wait for it to be fixed), or more than three tags pushed at once (no tag events at all).

Check

git log -1 --format=%B   # [skip ci] or [skip actions] in the message
gh pr view <number> --json mergeable --jq .mergeable   # CONFLICTING: fix the conflict first

Fix

Push a commit without the skip marker, fix the merge conflict, or push tags a few at a time.

The trigger is not where GitHub reads it: a schedule changed on a non-default branch (schedules run from the default branch only), or the file is outside .github/workflows or not .yml/.yaml. GitHub never sees the trigger, so it never fires.

Check

git ls-files .github/workflows   # the file is listed, ending in .yml or .yaml
gh repo view --json defaultBranchRef --jq .defaultBranchRef.name   # schedules run from this branch only

Fix

Move the file to .github/workflows/ with a .yml extension, and merge schedule changes to the default branch.

A job was renamed and its needs: still uses the old id. needs: is matched against ids exactly, so the old one is unknown.

Check

grep -n 'needs:' .github/workflows/ci.yml   # every name here must be a key under jobs:
actionlint .github/workflows/ci.yml   # names the job ids that do exist

Fix

Use the current id in needs:, and rename ids and their needs together.

needs: uses the job's display name: instead of its id. Only ids (the keys under jobs:) count, so a name such as Run tests is unknown.

Check

grep -n -B1 '    name:' .github/workflows/ci.yml   # the key on the line above name: is the id to use

Fix

Use the id, not the name.

The job is in another workflow file. needs: only reaches jobs in the same file.

Check

grep -ln '^  tests:' .github/workflows/*.yml   # the id lives in another file

Fix

Move the job into this file, call the other workflow as a reusable workflow, or chain the two with workflow_run.

secrets is used in an if:. Secrets are never available in if: conditions, at job or step level, so the name is unknown there.

Check

grep -n 'if:.*secrets\.' .github/workflows/*.yml   # any line printed is this cause

Fix

Turn the secret into a flag in the job's env: (HAS_TOKEN: ${{ secrets.TOKEN != '' }}) and test it in a step: if: env.HAS_TOKEN == 'true'. Or test something available, such as github.event_name or github.repository.

env or steps is used in a job-level if:. A job's if: is evaluated before the job has an env or any steps, so those names do not exist yet.

Check

grep -n -E '^    if:.*(env|steps)\.' .github/workflows/*.yml   # an if: at job indentation using env or steps

Fix

Use needs.<job>.outputs.<name>, vars or github in the job's if:, or move the condition to a step.

The name is misspelt or is not a context (secret.TOKEN, github.events). GitHub knows only its own context names, so any other word is unrecognized.

Check

actionlint .github/workflows/ci.yml   # 'undefined variable' names the bad word

Fix

Use the right name from GitHub's list of contexts.

The owner or repository name is wrong (actions/chekout). GitHub has no such repository, so the runner says repository not found.

Check

gh api repos/<owner>/<action-repo> --jq .full_name   # 404: no such repository, check the spelling

Fix

Correct the name.

The action is in a private or internal repository that does not allow access from this one. The runner cannot see it, so it is reported as not found too.

Check

gh api repos/<owner>/<action-repo> --jq .visibility   # private or internal: check that repository's Settings > Actions > General > Access

Fix

In the action's repository, allow access from other repositories in the organization (Settings > Actions > General > Access).

The ref after @ does not exist, or was deleted. The repository is found but not the version, so the message says unable to find version.

Check

git ls-remote https://github.com/<owner>/<action-repo> '<ref>'   # nothing printed: no tag or branch with that name
gh api repos/<owner>/<action-repo>/releases/latest --jq .tag_name   # an existing version to use

Fix

Use an existing tag, or better a full commit SHA with the version in a comment.

The included minutes ran out with no payment method, or with a spending limit of zero. Private repositories (and larger runners) use paid minutes, so GitHub stops starting jobs.

Check

gh api /users/<user>/settings/billing/usage   # or Settings > Billing and plans: minutes used against the included amount

Fix

Add a payment method or raise the spending limit, or wait for the monthly reset. Making the repository public, or using a self-hosted runner, also avoids hosted minutes.

A payment failed or the account is locked for billing. GitHub blocks paid usage until it is fixed, with the same message.

Check

# Settings > Billing and plans: a banner about a failed payment or a locked account

Fix

Update the payment method and retry the payment.

The repository belongs to an organization, and the organization's billing has the problem, not yours. Minutes are charged to the repository's owner.

Check

gh api /organizations/<org>/settings/billing/usage   # the organization's usage

Fix

Ask an organization owner or billing manager to fix the payment method or limit.

The file on the branch you run from has no workflow_dispatch: under on:. GitHub reads the trigger from that branch's copy, so a trigger on another branch does not count.

Check

gh workflow view ci.yml --ref <branch> --yaml | grep -n workflow_dispatch   # nothing printed: this branch's file has no trigger

Fix

Add workflow_dispatch: to on: on that branch.

No --ref was given, so GitHub used the default branch, whose file lacks the trigger. The Run workflow button also appears only once the default branch has it.

Check

gh workflow view ci.yml --yaml | grep -n -A4 '^on:'   # the file on the default branch

Fix

Merge the trigger to the default branch. Before that, if GitHub already knows the workflow (it is on the default branch or has run before), gh workflow run ci.yml --ref <branch> runs it from a branch whose file has the trigger.

A command really failed: a test, a build, a linter. Run steps use bash -e, so the first failing command stops the step and its code becomes the step's.

Check

gh run view <run-id> --log-failed   # the lines before the error are the failing command's own output

Fix

Fix what the command reports. Reproduce it locally with the same commands under bash -e script.sh.

A command uses 1 for a normal result: grep with no match, diff when files differ, a test or [ ] that is false. Under bash -e that still stops the step, with no error printed.

Check

gh run view <run-id> --log-failed | tail -5   # the last command is a grep, diff or test, with no error message

Fix

Accept the expected code where you call it: grep -c x f || true, or if grep -q x f; then ...; fi. Do not use continue-on-error to hide it.

The runner image does not include the tool. The step calls it, and there is nothing to run.

Check

command -v foo || echo 'foo is not on PATH'   # in the failing step

Fix

Install it in a step, use a setup-* action (setup-node, setup-python, ...), or run the job in a container that has it. Pin the version.

It is installed in a directory that is not on PATH, or that was added to $GITHUB_PATH in the same step. $GITHUB_PATH changes apply from the next step, so the current step still cannot find it.

Check

echo "$PATH" | tr ':' '\n'   # is the install directory listed?
ls -l <install-dir>/foo   # the file exists, so only PATH is missing it

Fix

Write the directory to $GITHUB_PATH in one step and use the tool from the next one, or call it by its full path.

It was installed in another job, or by a setup step that was skipped. Each job runs on a fresh machine, so nothing carries over.

Check

gh run view <run-id> --log | grep -n -i 'setup\|install'   # the install step is in another job, or was skipped

Fix

Install the tool in every job that uses it, or pass built files between jobs as an artifact.

The step used more memory than the runner has: parallel test workers, a large webpack or Gradle build, a Docker build. The kernel kills the biggest process to keep the machine alive, which gives 137.

Check

free -m   # in a step before the heavy one: the memory available
sudo dmesg | grep -i -E 'killed process|out of memory'   # in a later step with if: always(); a line here confirms the out-of-memory killer

Fix

Use less memory at once: fewer parallel workers (jest --maxWorkers=2, make -j2, Gradle --max-workers=2), or split the job. Otherwise use a larger runner.

Node.js reached its own heap limit, which can be lower than the machine's memory. It stops itself with JavaScript heap out of memory instead of being killed.

Check

gh run view <run-id> --log-failed | grep -i 'heap out of memory'   # present: Node.js's own limit, not the machine's

Fix

Raise the heap with NODE_OPTIONS=--max-old-space-size=4096 when the runner has that memory, or reduce parallel work.

A container with a memory limit (docker run --memory, options: --memory on a service) was killed when it reached that limit. Any SIGKILL gives 137.

Check

docker inspect <container> --format '{{.State.OOMKilled}}'   # true: the container's own limit, not the runner's

Fix

Raise the container's limit to what it really needs, or reduce its memory use.

The machine ran out of memory or CPU, the same pressure that gives exit code 137. The runner process itself is starved or killed, so it stops reporting.

Check

gh run view <run-id> --log | tail -50   # the last step that ran: a heavy build or test?

Fix

Reduce memory and CPU use in that step (fewer parallel workers, smaller builds) or use a larger runner.

On a self-hosted runner, a step stopped or restarted the runner, or the machine shut down, rebooted or lost its network. GitHub stops hearing from it.

Check

# self-hosted: the runner's _diag/Runner_*.log and _diag/Worker_*.log around the time of the job
journalctl -u 'actions.runner.*' --since '<time>'   # a stop or restart of the runner service at that time

Fix

Check the machine's memory, disk and network, and make sure nothing (updates, autoscaling, a reboot) stops the runner service during a job.

A hosted runner was lost for a reason outside your workflow. It is rare, and the same job passes when run again.

Check

gh run view <run-id> --log | tail -20   # the last step was a light one, and other runs of this job pass

Fix

Re-run the job once (gh run rerun <run-id> --failed). If it happens again, treat it as the first cause.

fail-fast: another job in the same matrix failed, and GitHub canceled the rest (the default). The canceled jobs show this message, not the real failure.

Check

gh run view <run-id>   # one matrix job failed (X), the others show as canceled

Fix

Fix the first failure. Set fail-fast: false to see every matrix result.

A newer run in the same concurrency group with cancel-in-progress: true replaced this one.

Check

grep -n -A2 concurrency .github/workflows/*.yml   # cancel-in-progress: true
gh run list --workflow ci.yml --limit 5   # a newer run on the same branch

Fix

Nothing to fix if the newer run is the one you want; read that run instead.

Someone canceled the run in the Actions tab or with gh run cancel.

Check

gh run view <run-id>   # the annotation says: The run was canceled by <user>

Fix

Ask why, and re-run it if it should finish.

A process never exits: a server started in the foreground, a watch mode, a test runner waiting for file changes. The step waits for it until the limit.

Check

gh run view <run-id> --log | tail -50   # the last output is a server 'listening on' or 'watching for changes'

Fix

Start servers in the background (npm start &) and wait for them with a health check; run tests without watch mode (CI=true, --watchAll=false).

A command waits for input that never comes: a confirmation prompt, a password, a licence question. A job has no terminal, so it waits until the limit.

Check

gh run view <run-id> --log | tail -20   # the last line is a question, such as 'Continue? [y/N]'

Fix

Pass the non-interactive flag (-y, --yes, --non-interactive, DEBIAN_FRONTEND=noninteractive).

The work is slow or deadlocked and there is no tighter timeout, so it uses the full 360 minutes.

Check

gh run list --workflow ci.yml --limit 10   # usual durations: this run took far longer

Fix

Set timeout-minutes close to the real duration so a hang fails fast, and split or cache the slow work.

No runner has all the requested labels: a typo (ubuntu-lastest) or a self-hosted label no runner has. GitHub waits for a runner that never comes.

Check

gh run view <run-id> --log | grep -i 'requested labels'   # compare with a real label such as ubuntu-latest
gh api repos/<owner>/<repo>/actions/runners --jq '.runners[] | {name, status, busy, labels: [.labels[].name]}'   # needs admin access; no runner has all the labels

Fix

Fix the label in runs-on:.

The self-hosted runner with those labels is offline or busy with another job. The job waits until it is free.

Check

gh api repos/<owner>/<repo>/actions/runners --jq '.runners[] | {name, status, busy}'   # status offline, or busy true

Fix

Start the runner service, or add runners.

The organization's runner group does not include this repository (public repositories are left out unless allowed). The runner exists but may not take this job.

Check

gh api orgs/<org>/actions/runner-groups --jq '.runner_groups[] | {name, visibility, allows_public_repositories}'   # limited to selected repositories, or not allowing public ones

Fix

Add the repository to the runner group, or allow public repositories if that is intended.

A concurrency limit is reached: the plan's limit on jobs running at once, or a larger runner's maximum. Jobs wait for a free slot.

Check

gh run list --status in_progress --limit 50   # many runs in progress at once

Fix

Wait, cancel superseded runs with concurrency:, or raise the limits.

The build, its images and its caches need more space than is free. Large Docker builds and dependency caches are the usual cause.

Check

df -h   # in a step before the build: little space left on /
du -sh ~/.cache ~/.npm 2>/dev/null; docker system df   # in a later step with if: always(): what grew

Fix

Slim the build (multi-stage images, a .dockerignore), and remove images and build cache you no longer need between steps.

Preinstalled toolchains you do not use take several GB of a hosted runner's disk, leaving less for your build.

Check

du -sh /usr/local/lib/android /usr/share/dotnet /opt/ghc   # several GB each that your build does not need

Fix

Remove unused preinstalled toolchains before the build (for example sudo rm -rf /usr/local/lib/android /usr/share/dotnet /opt/ghc on a hosted runner), or use a larger runner.

On a self-hosted runner, work directories, images and caches from earlier jobs pile up. Nothing removes them by default.

Check

df -h; docker system df   # self-hosted: images and build cache left by earlier jobs

Fix

Clean the work directory and Docker on a schedule, or use ephemeral runners that start clean for every job.

actions/checkout makes a shallow clone of one commit (fetch-depth: 1) without tags. describe has no tags and no history to search.

Check

git rev-parse --is-shallow-repository   # true: only the last commit was fetched
git tag | wc -l   # 0: no tags were fetched

Fix

Set fetch-depth: 0 on actions/checkout. git fetch --tags alone is not enough in a shallow clone, because the history back to the tag is still missing; use git fetch --unshallow --tags.

The repository has only lightweight tags. git describe without --tags uses annotated tags only, so it says No annotated tags can describe.

Check

git describe --tags   # works: the tags are lightweight

Fix

Call git describe --tags, or create annotated tags (git tag -a v1.0.0 -m v1.0.0).

The repository has no tags yet (a new repository, or a fork without tags). There is nothing to describe from.

Check

git ls-remote --tags origin | head   # nothing printed: no tags on the remote

Fix

Create the first tag, or use git describe --tags --always to fall back to the commit id.

The steps run on the runner but connect to the service by its name. Service names resolve only inside a job container (the job's Docker network), so the lookup fails.

Check

getent hosts postgres || echo 'no such name: this step runs on the runner, use localhost'

Fix

On the runner, connect to localhost with the port mapped; in a job with container:, use the service name.

The port is not mapped to the runner. Without ports:, the service listens only on its Docker network, so localhost refuses the connection.

Check

docker ps   # PORTS column empty for the service: the port is not mapped

Fix

Add ports: ["5432:5432"] to the service.

The service is not ready yet. The container starts, but the database needs a few seconds before it accepts connections, so early connections are refused.

Check

pg_isready -h localhost -p 5432   # 'no response' at first, then 'accepting connections': it was not ready yet

Fix

Add a health check in options (--health-cmd pg_isready --health-interval 5s --health-retries 10); the job then waits for it before the steps.

The pull is anonymous. Docker Hub limits anonymous pulls per IP address, and a hosted runner's address is shared with many other jobs, so the limit can be used up before your job starts.

Check

gh run view <run-id> --log | grep -i -B3 toomanyrequests   # which pull failed: a build, a services: or a container: image
grep -n -A3 'docker/login-action\|credentials:' .github/workflows/*.yml   # nothing printed: every pull is anonymous

Fix

Log in before pulling: docker/login-action with a Docker Hub username and access token stored as secrets. services: and container: images are pulled before any step, so give them credentials: too.

You are logged in, but the account's own pull limit is used up: many jobs or matrix legs pull the same images with one account.

Check

gh run list --limit 20   # many runs at once, all pulling the same images

Fix

Pull less: cache layers, reuse built images, or keep copies of your base images in ghcr.io or your own registry.

The job runs in a container as a different user from the owner of the workspace. The workspace is mounted from the runner, so its owner id differs, and git refuses.

Check

id -u; stat -c %u "$GITHUB_WORKSPACE"   # in the failing step: two different numbers

Fix

Mark the workspace safe before the git commands: git config --global --add safe.directory "$GITHUB_WORKSPACE".

actions/checkout marked the directory safe only for its own git commands, in a temporary config. Later steps do not have that setting.

Check

git config --show-origin --get-all safe.directory   # nothing printed: no safe.directory for this step's git

Fix

Add the same safe.directory line once in the job's first step after checkout.

On a self-hosted runner, the work folder was created by another user: a different service account, or a step that ran as root.

Check

ls -ldn "$GITHUB_WORKSPACE" "$GITHUB_WORKSPACE/.git"   # the owner uid differs from the runner's user

Fix

Run the runner service as one user and give that user ownership of its work folder (chown -R), instead of running steps as root.

A value with line breaks (JSON, a key, command output) was written as name=value. Every line must be name=value, so the second line has no name.

Check

grep -n -v -E '^[A-Za-z_][A-Za-z0-9_]*(=|<<)' "$GITHUB_ENV" | cut -d: -f1   # at the end of the step: line numbers that are not NAME=value or NAME<<DELIMITER, without printing values

Fix

Use the delimiter form: { echo 'CONFIG<<EOF'; cat config.json; echo 'EOF'; } >> "$GITHUB_ENV", or make JSON one line with jq -c.

The delimiter form is used, but the closing delimiter is not alone on its own line: the value has no final line break, so EOF lands at the end of its last line, or the value itself contains the delimiter. The runner never finds the end (Matching delimiter not found).

Check

tail -c 1 config.json | od -c   # no \n: the file has no final line break

Fix

Print a line break before the delimiter (echo before echo 'EOF'), and use a random delimiter for content you did not write: d=$(openssl rand -hex 8).

YAML read an unquoted 3.10 as the number 3.1. Numbers lose their trailing zero, so setup-python asks for 3.1, which does not exist.

Check

grep -n -A2 'python-version' .github/workflows/*.yml   # 3.10 without quotes becomes 3.1

Fix

Quote versions: "3.10".

The version you wrote has no build for this runner image or architecture: a very old or very new Python, or a new image the builds do not cover yet.

Check

# the version in the error is exactly the one you wrote: look it up in the versions-manifest.json linked in the message

Fix

Choose a version listed for this image, or run on an image that has it.

A permissions: block leaves out the scope the call needs. Every scope not listed becomes none, so the token cannot make this call.

Check

gh run view <run-id> --log | grep -A15 'GITHUB_TOKEN Permissions'   # Set up job: the scopes the token really had; the needed scope is missing or read
grep -n -A6 'permissions:' .github/workflows/<file>.yml   # the scopes asked for

Fix

Add the one scope needed to that job: pull-requests: write to comment on a pull request, contents: write to create a release.

There is no permissions: block and the repository or organization default is read, so every scope is read-only.

Check

gh api repos/<owner>/<repo>/actions/permissions/workflow --jq .default_workflow_permissions   # read

Fix

Add a permissions: block with the one scope needed, rather than changing the default to write.

The run is a pull request from a fork, or a Dependabot run. Forks always get a read-only token, whatever the file asks; Dependabot runs get read-only by default.

Check

gh api repos/<owner>/<repo>/actions/runs/<run-id> --jq '{event, actor: .actor.login, head: .head_repository.full_name}'   # another head repository: a fork; dependabot[bot]: Dependabot

Fix

For Dependabot runs, a permissions: block can raise it. For forks, comment from a separate trusted workflow (workflow_run) that never runs the fork's code.

The call targets another repository. The GITHUB_TOKEN works only on the repository the workflow runs in.

Check

gh run view <run-id> --log-failed | grep -i 'repos/'   # the API path names another owner/repo

Fix

Use a GitHub App token for that repository (actions/create-github-app-token) with only the permission needed.

The step uses a personal access token that lacks the scope or the repository. The message then says by personal access token.

Check

gh auth status   # with GH_TOKEN set to that token: its scopes, not the token

Fix

Give the token the one permission on that repository (fine-grained), or use the GITHUB_TOKEN where it can do the job.

The GITHUB_TOKEN has no packages: write in this job (fork pull requests never get it). Login only needs a valid token; the push needs write.

Check

gh run view <run-id> --log | grep -A15 'GITHUB_TOKEN Permissions'   # Set up job: the scopes the token really had; Packages: write?

Fix

Add packages: write to the publishing job only.

The package already exists and this repository has no write access to it. A package created by another repository or by hand is not writable by this repository's token until you grant it.

Check

gh api orgs/<org>/packages/container/<name> --jq .repository.full_name   # with a token that can read packages; another or no repository: not linked to this one

Fix

Open the package's settings, Manage Actions access, and add this repository with the Write role.

The image name is under another owner (ghcr.io/other-org/app). The GITHUB_TOKEN can publish only under the repository's owner.

Check

grep -n 'ghcr.io/' .github/workflows/*.yml   # the name after ghcr.io/ must be this repository's owner, in lower case

Fix

Push to ghcr.io/<owner>/<name> with the repository's owner.

The run is a pull request from a fork, or a Dependabot run. GitHub gives them no Actions secrets, so untrusted code cannot read them.

Check

gh api repos/<owner>/<repo>/actions/runs/<run-id> --jq '{event, actor: .actor.login, head: .head_repository.full_name}'   # another head repository: a fork; dependabot[bot]: Dependabot
gh secret list --app dependabot   # Dependabot runs read only these

Fix

Skip the step for forks (if: github.event.pull_request.head.repo.full_name == github.repository); add what Dependabot needs to Dependabot secrets.

It is an environment secret and the job has no environment:. Only jobs that name the environment receive its secrets.

Check

gh secret list --env production   # the secret is here
grep -n 'environment:' .github/workflows/<file>.yml   # not set on this job

Fix

Add environment: production to the job.

The step is in a reusable workflow and the caller did not pass the secret. Called workflows receive only the secrets passed to them.

Check

grep -n -A4 'uses: .*\.github/workflows/' .github/workflows/*.yml   # no secrets: under the calling job

Fix

Pass it (secrets: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}) or use secrets: inherit (same organization or enterprise).

The name is misspelt, or it is an organization secret not shared with this repository. Either way the expression finds nothing and gives an empty string, with no error.

Check

[ -n "$DEPLOY_TOKEN" ] && echo set || echo empty   # in the step, with env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}; presence only, never the value
gh secret list   # the exact name
gh secret list --org <org>   # VISIBILITY selected: is this repository on its list?

Fix

Fix the name, or share the organization secret with this repository.

The step does not set GH_TOKEN. Actions does not put the token in a step's environment by itself.

Check

[ -n "$GH_TOKEN" ] && echo 'GH_TOKEN set' || echo 'GH_TOKEN empty'   # in the step; shows presence, not the token

Fix

Set GH_TOKEN: ${{ github.token }} in the step's env:.

GH_TOKEN comes from a secret that is empty in this run, such as a fork or Dependabot pull request. An empty variable counts as not set.

Check

grep -n 'GH_TOKEN' .github/workflows/*.yml   # set from secrets.<name>?
gh api repos/<owner>/<repo>/actions/runs/<run-id> --jq '{event, actor: .actor.login, head: .head_repository.full_name}'   # another head repository: a fork; dependabot[bot]: Dependabot

Fix

Use ${{ github.token }} where it is enough, or skip the step for forks.

The job's GITHUB_TOKEN has contents: read: the default for repositories and organizations created since 2023, or a permissions: block without contents: write. Reading is enough to check out, not to push.

Check

gh run view <run-id> --log | grep -A15 'GITHUB_TOKEN Permissions'   # Set up job: the scopes the token really had; Contents: read means this job cannot push
gh api repos/<owner>/<repo>/actions/permissions/workflow --jq .default_workflow_permissions   # read: the default

Fix

Grant contents: write to that job only. If the push then fails with GH006 or GH013, the branch is protected: open a pull request instead.

The run is a pull request from a fork. Its token is always read-only, whatever the file asks.

Check

gh api repos/<owner>/<repo>/actions/runs/<run-id> --jq '{event, actor: .actor.login, head: .head_repository.full_name}'   # another head repository: a fork; dependabot[bot]: Dependabot

Fix

Do not push from fork pull requests; push from a trusted workflow after the merge.

The push goes to another repository. The GITHUB_TOKEN can write only to the repository the workflow runs in.

Check

git remote get-url origin   # in the step: another owner/repo

Fix

Use a GitHub App token with Contents: write on that repository.

The commit or tag was pushed with the GITHUB_TOKEN, which actions/checkout sets up for git by default. By design that push starts no runs.

Check

gh run list --event push --limit 5   # no run for the pushed commit or tag
grep -n -B3 'git push\|gh release create' .github/workflows/*.yml   # pushed with checkout's credentials or GH_TOKEN: ${{ github.token }}

Fix

Call the next workflow directly (workflow_call, or gh workflow run, which the GITHUB_TOKEN may start), or push with a GitHub App token.

The push happened, but the target workflow's filters do not match it (a branches-only trigger for a tag). It would not run with any token.

Check

gh workflow view release.yml --yaml | grep -n -A6 '^on:'   # tags: missing

Fix

Add tags: under on: push: in that workflow.

The hourly limit is used up: the GITHUB_TOKEN allows 1,000 REST requests per hour per repository (15,000 for repositories in a GitHub Enterprise Cloud account). A loop calling the API once per item uses it up fast.

Check

gh api rate_limit --jq .resources.core   # remaining 0 and a reset time: the hourly quota (this call does not count)

Fix

Use list endpoints with per_page=100 and --paginate, or GraphQL (gh pr list --json), cache results, or use a GitHub App token with a higher limit.

A secondary rate limit: too many requests at once, or content created too fast. It applies whatever is left of the hourly quota, and the message says exceeded a secondary rate limit.

Check

gh api rate_limit --jq .resources.core   # requests still left: a secondary limit
gh run view <run-id> --log | grep -i 'secondary rate limit\|retry-after'

Fix

Make calls one at a time, wait as long as the retry-after header says, and avoid parallel jobs writing at the same moment.

A paths or branches filter skipped the whole workflow. A skipped workflow reports nothing, so the check stays Expected (a job skipped by if: reports success instead).

Check

gh pr checks <number>   # the checks that did report: this one is missing
gh workflow view ci.yml --yaml | grep -n -A6 'pull_request:'   # paths or branches that exclude this pull request

Fix

Let the workflow run for every pull request and skip work inside the job with if:.

The required name does not match any job's check name: the job was renamed, or a matrix job's name includes its values (test (20)). GitHub matches names exactly.

Check

gh api repos/<owner>/<repo>/branches/main/protection/required_status_checks --jq '.contexts'   # required by branch protection
gh api repos/<owner>/<repo>/rules/branches/main --jq '.[] | select(.type == "required_status_checks") | .parameters.required_status_checks'   # required by rulesets

Fix

Make the required name match the job's check name exactly, or rename the job back.

The workflow does not run on this event (push only, not pull_request), or the pull request has a merge conflict, so pull_request workflows did not run.

Check

gh pr view <number> --json mergeable --jq .mergeable   # CONFLICTING: no pull_request runs until it is fixed
grep -n -A4 '^on:' .github/workflows/*.yml   # pull_request: listed?

Fix

Add pull_request: to the workflow, or fix the merge conflict.

The workflows that report required checks do not listen to merge_group. The queue sends that event, not pull_request or push, so they never run on its branch.

Check

grep -n -A6 '^on:' .github/workflows/*.yml   # merge_group: missing from a workflow that reports a required check

Fix

Add merge_group: to the on: of every workflow that provides a required check.

The step has no shell:, so Windows uses pwsh. Many Unix commands there are aliases for cmdlets with different options.

Check

# the step log shows: shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"

Fix

Set shell: bash on the step or in defaults: run: shell:; Git Bash is on Windows runners. Or write the step in PowerShell.

The command does not exist on Windows at all, so PowerShell or cmd says it is not recognized.

Check

Get-Command <tool> -ErrorAction SilentlyContinue   # in a pwsh step: nothing printed, the tool is not on this runner

Fix

Use shell: bash (Git Bash has the common Unix tools), or install the tool.

shell: cmd is used. cmd reports only the last command's exit code, so earlier errors pass silently and the failure shows up later.

Check

grep -n 'shell: cmd' .github/workflows/*.yml

Fix

Use pwsh or bash, which stop on errors.

actions/checkout does not fetch LFS objects by default, so only the pointers are checked out.

Check

head -1 data/prices.csv   # in a step: 'version https://git-lfs.github.com/spec/v1'
git lfs ls-files   # the file is tracked by LFS

Fix

Set lfs: true on actions/checkout.

LFS is fetched, but the download failed: the object was never pushed, or the account's LFS quota is used up. The pointer stays in place.

Check

gh run view <run-id> --log | grep -i 'lfs'   # errors about a missing object or a quota

Fix

Push the missing objects from a clone that has them (git lfs push --all origin), or raise the LFS quota.

The output really contains a secret: a token in a URL, a connection string.

Check

gh run view <run-id>   # ANNOTATIONS: Skip output 'image' since it may contain secret

Fix

Pass only the non-secret part, and add the secret in the job that uses it.

A secret holds a value that is not secret and also appears in the output: a registry host, a region, an account id. The runner masks any match, so the output is dropped.

Check

gh secret list   # settings such as REGISTRY or REGION stored as secrets

Fix

Keep non-sensitive settings in vars instead of secrets.

A personal access token expired or was revoked, or a GitHub App token was used after it expired (they last one hour).

Check

gh auth status   # in the step, with GH_TOKEN set to the same token; shows the account, not the token

Fix

Create a new token, store it with gh secret set NAME, and re-run. Where the GITHUB_TOKEN can do the job, use it: it is new for every run. For other repositories, prefer a GitHub App token from actions/create-github-app-token, created in the job that uses it.

The secret holds the wrong value: extra spaces, a line break, or a different token pasted.

Check

printf %s "$TOKEN" | wc -c; case "$TOKEN" in *[[:space:]]*) echo 'has whitespace';; esac   # length and stray spaces, not the value

Fix

Set the secret again with gh secret set NAME, which prompts for the value, so no newline is added.

A secret with the same name in the environment or the organization holds an older token. Environment secrets win over repository secrets, which win over organization ones.

Check

gh secret list; gh secret list --env <env>; gh secret list --org <org>   # the same name in more than one place, and when each was updated

Fix

Update or delete the stale copy, so one place holds the token.

The with: key is missing or spelt differently from the action's action.yml.

Check

grep -n -A6 'uses: <the action>' .github/workflows/*.yml   # the input is missing under with:, or spelt differently

Fix

Pass the input under with: with the exact name from the action's action.yml.

The value comes from a secret that is empty in this run. Pull requests from forks and Dependabot get no Actions secrets, and a misspelt secret name is empty without an error.

Check

gh secret list   # the secret named in with: exists, with that exact name
gh api repos/<owner>/<repo>/actions/runs/<run-id> --jq '{event, actor: .actor.login, head: .head_repository.full_name}'   # another head repository: a fork; dependabot[bot]: Dependabot

Fix

Make sure the secret exists for this run, and skip the step for forks with if: github.event.pull_request.head.repo.full_name == github.repository. For a GitHub token, ${{ github.token }} is always set.

The other repository is private and the GITHUB_TOKEN can read only the repository the workflow runs in. Git has no other credentials, so it wants a user name, or GitHub answers repository not found.

Check

cat .gitmodules   # submodule URLs pointing to other private repositories
gh api repos/<owner>/<other-repo> --jq .full_name   # with the token the step uses; 404: it cannot see that repository

Fix

Give checkout a token that can read the other repository, token: ${{ secrets.READ_TOKEN }} (a fine-grained token with Contents: read on it, or a GitHub App token), with submodules: recursive for submodules; or an SSH deploy key with ssh-key:.

A package manager, such as Go modules, fetches the private repository with its own git call, which does not use checkout's credentials.

Check

go env GOPRIVATE   # empty: Go treats the module as public

Fix

Set GOPRIVATE, and give git credentials for github.com in that step, for example gh auth setup-git with GH_TOKEN set to a read-only token.

checkout ran with persist-credentials: false, so later git commands in the job have no credentials.

Check

grep -n 'persist-credentials' .github/workflows/*.yml   # false

Fix

Give credentials to the one step that needs them, rather than persisting them for every step.

The push used the GITHUB_TOKEN, which can never be given the workflows permission, so any commit touching a workflow file is rejected.

Check

git diff --name-only origin/main...HEAD | grep '^.github/workflows/'   # any file listed needs the workflows permission

Fix

Leave workflow files out of the bot's commits, or push with a GitHub App token that has Workflows: write. Changes to workflows deserve a human review anyway.

A GitHub App without Workflows: write, or a personal access token without the workflow scope (classic) or Workflows: write (fine-grained). The message then names the app or a personal access token.

Check

gh auth status   # with GH_TOKEN set to that token: the scopes it has, without 'workflow'

Fix

Grant Workflows: write (or the workflow scope) only to the token that should change workflows.

The key changes every run, because it includes github.sha or run_id. No run ever looks for a key an earlier run saved.

Check

grep -n 'key:' .github/workflows/*.yml   # github.sha or run_id in the key

Fix

Key on the contents: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}, with restore-keys for a prefix match.

The cache was saved on a branch this run cannot read. A run reads its own branch, the default branch and, for a pull request, its base branch; caches saved by pull requests are not shared back.

Check

gh cache list --key npm- --json key,ref,lastAccessedAt   # entries exist, but only on another ref

Fix

Let the default branch save the cache (run the workflow on push to main), so every branch can read it.

The entry was removed: after 7 days unused, or when the repository passed its cache size limit and older entries were evicted.

Check

gh cache list --sort last_accessed_at --order asc --limit 5   # few or no entries left

Fix

Keep caches small and few, and save from the default branch regularly.

path: differs from the step that saved it. The path is part of the cache version, so the same key still misses.

Check

gh run view <run-id> --log | grep -i cache   # the key it looked for, and whether a run saved one
grep -n -A4 'actions/cache' .github/workflows/*.yml   # the same path: everywhere?

Fix

Use the same path: in every step that saves and restores that cache.

An earlier run already saved an entry with this exact key.

Check

gh cache list --key npm-   # an entry with this exact key already exists

Fix

Nothing is broken if the content is the same. To store new content, change the key: include hashFiles(...) of the lockfile.

Several jobs in this run save the same key at once, often matrix jobs that share one key while building different content.

Check

grep -n 'key:' .github/workflows/*.yml   # no matrix values in the key of a matrix job

Fix

Add the matrix values to the key (${{ runner.os }}-${{ matrix.node }}).

The dependency file has another name or path than the defaults (requirements.txt, pyproject.toml).

Check

git ls-files '*requirements*' pyproject.toml   # your file has another name or sits elsewhere

Fix

Add cache-dependency-path: requirements-dev.txt (your file), or add a requirements file.

actions/checkout did not run before setup-python, so the workspace is empty.

Check

grep -n -B8 'setup-python' .github/workflows/*.yml   # no actions/checkout before it

Fix

Run actions/checkout first.

No lockfile is committed. The cache has nothing to key on.

Check

git ls-files | grep -E 'package-lock|yarn.lock|pnpm-lock'   # nothing printed

Fix

Commit the lockfile.

The lockfile is in a subfolder. setup-node looks in the root unless told otherwise.

Check

git ls-files '*package-lock.json'   # e.g. app/package-lock.json

Fix

Set cache-dependency-path: app/package-lock.json.

actions/checkout did not run before setup-node, so the workspace is empty.

Check

grep -n -B8 'setup-node' .github/workflows/*.yml   # no actions/checkout before it

Fix

Run actions/checkout first.

The name differs from the one used at upload.

Check

gh api repos/<owner>/<repo>/actions/runs/<run-id>/artifacts --jq '.artifacts[] | {name, expired}'   # the names that exist

Fix

Use the same name in both steps, best from one env variable.

The uploading job did not run, failed, or found no files, so nothing was uploaded.

Check

gh run view <run-id>   # the upload job was skipped or failed, or its log warns 'No files were found'

Fix

Fix the upload job first.

The download runs before the upload has finished, because the downloading job has no needs: on the uploading one. Jobs run in parallel by default.

Check

grep -n -B2 -A2 'needs:' .github/workflows/<file>.yml   # the downloading job does not need the uploading one

Fix

Add needs: <upload-job> to the downloading job.

The artifact is from another run, or it expired (90 days by default, or the upload's retention-days).

Check

gh api repos/<owner>/<repo>/actions/runs/<other-run-id>/artifacts --jq '.artifacts[] | {name, expired}'   # expired true, or a different run

Fix

For another run, pass run-id and github-token to download-artifact. Raise retention-days if it must live longer.

Matrix jobs upload with the same name. The first one wins and the rest fail.

Check

grep -n -A3 upload-artifact .github/workflows/*.yml   # name: without matrix values in a matrix job

Fix

Put the matrix values in the name; merge later with download-artifact and pattern: plus merge-multiple: true.

The same job uploads the name again on purpose: a second upload step, or a re-run of the job.

Check

grep -c 'name: build' .github/workflows/<file>.yml   # more than one upload with that name

Fix

Set overwrite: true on the upload that should replace it.

The build wrote somewhere else, or did not run.

Check

ls -la "$GITHUB_WORKSPACE/dist"   # in a step before the upload: missing or empty

Fix

Fix the path, or the build step.

path: is relative to the workspace. working-directory and defaults.run.working-directory apply to run: steps only, not to uses: steps, so a build in app/ writes to app/dist.

Check

grep -n 'working-directory' .github/workflows/<file>.yml   # set for run steps: add it to path:

Fix

Write the full path from the workspace: path: app/dist.

Since upload-artifact v4.4, files and folders whose names start with a dot are left out unless include-hidden-files: true. If everything is hidden, nothing is found.

Check

ls -A dist   # only names starting with a dot

Fix

Set include-hidden-files: true, after checking that no secrets (such as .env) are inside.

upload-artifact or download-artifact v3 or older. Those versions used a storage service that no longer exists.

Check

grep -rn 'artifact@' .github/workflows   # @v3, @v2 or @v1, or the version comment beside a SHA

Fix

Move to a supported major (upload-artifact v6, download-artifact v7 or later) and check the changes in its notes: since v4, names are unique per run.

actions/cache older than v3.4.0 or v4.2.0, including SHAs pinned to those versions. The old cache service they called was shut down.

Check

grep -rn 'actions/cache@' .github/workflows   # check each version, or the version comment beside a SHA

Fix

Move to a current actions/cache major.

You use an older major of an official action that runs on Node.js 20.

Check

gh run view <run-id>   # ANNOTATIONS: the actions and versions listed

Fix

Use majors that run on Node.js 24: checkout v5+, setup-node v5+, setup-python v6+, cache v5+, upload-artifact v6+, download-artifact v7+.

A third-party or your own action declares using: node20 in its action.yml.

Check

grep -rn "using: *.node20" .github/actions action.yml 2>/dev/null   # your own actions

Fix

Change it to node24 and test it, or update the third-party action to a release that does.

Your own workflow or script still prints the old command.

Check

grep -rn 'set-output\|save-state' .github   # your files

Fix

Write name=value to $GITHUB_OUTPUT (state: $GITHUB_STATE).

An action you use prints it, from an old version.

Check

gh run view <run-id>   # ANNOTATIONS: the step that printed it

Fix

Update that action.

The job's permissions lack id-token: write: a permissions: block that leaves it out. Without it, the runner does not offer an OIDC token to the job.

Check

[ -n "$ACTIONS_ID_TOKEN_REQUEST_URL" ] && echo 'OIDC available' || echo 'no id-token: write in this job'   # in the job, before the action
gh run view <run-id> --log | grep -A15 'GITHUB_TOKEN Permissions'   # Set up job: the scopes the token really had; IdToken: write?

Fix

Add id-token: write to the deploy job's permissions only.

The job is in a reusable workflow, and the calling job did not grant id-token: write. A called workflow cannot have more permissions than its caller.

Check

grep -n -B2 -A6 'uses: .*\.github/workflows/' .github/workflows/*.yml   # the calling job's permissions

Fix

Grant id-token: write in the calling job too.

The run is a pull request from a fork, which never gets an OIDC token.

Check

gh api repos/<owner>/<repo>/actions/runs/<run-id> --jq '{event, actor: .actor.login, head: .head_repository.full_name}'   # another head repository: a fork; dependabot[bot]: Dependabot

Fix

Skip the deploy for fork pull requests.

role-to-assume is empty, for example from a variable or secret this run cannot read. The action then tries other providers and fails with the second line alone.

Check

grep -n -A6 'configure-aws-credentials' .github/workflows/*.yml   # where role-to-assume comes from

Fix

Set role-to-assume from a value the run can read (a vars value, or the ARN written in the file).

The sub claim differs from the policy. A job with environment: sends repo:<owner>/<repo>:environment:<name> instead of repo:<owner>/<repo>:ref:refs/heads/<branch>; pull requests send :pull_request, tags :ref:refs/tags/<tag>; and an organization or repository can customise the format.

Check

aws iam get-role --role-name <role> --query Role.AssumeRolePolicyDocument   # the sub and aud it expects
curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" | jq -r '.value | split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson | {sub, aud}'   # in the job: the claims it sends, not the token
gh api repos/<owner>/<repo>/actions/oidc/customization/sub   # use_default false: a custom sub format

Fix

Make the job match the trust policy (often environment: production), or narrow the policy to the job's exact sub. Do not widen it with wildcards.

A pattern with * sits under StringEquals, which compares literally, so it never matches.

Check

aws iam get-role --role-name <role> --query Role.AssumeRolePolicyDocument   # StringEquals with a * in the sub

Fix

Write the exact sub under StringEquals, or use StringLike for a deliberate, narrow pattern.

aud is not sts.amazonaws.com, or the account has no OIDC provider for token.actions.githubusercontent.com, or the role is in another account than the provider.

Check

aws iam list-open-id-connect-providers   # token.actions.githubusercontent.com in the role's account?

Fix

Create the provider in the role's account, and keep the audience sts.amazonaws.com (the action's default).

The branch is not in the environment's list of allowed branches.

Check

gh api repos/<owner>/<repo>/environments/production --jq .deployment_branch_policy
gh api repos/<owner>/<repo>/environments/production/deployment-branch-policies --jq '.branch_policies[] | {name, type}'   # the branch and tag patterns allowed

Fix

Deploy from an allowed branch, or add the branch to the policy if it really should deploy.

The run is for a tag and the policy lists only branches. The message then says Tag "v1.2.0" is not allowed.

Check

gh api repos/<owner>/<repo>/environments/production/deployment-branch-policies --jq '.branch_policies[] | select(.type == "tag")'   # nothing printed: no tag allowed

Fix

Add a tag pattern (such as v*) to the policy.

The group has cancel-in-progress: true, so a new run cancels the running one.

Check

grep -n -A2 concurrency .github/workflows/*.yml   # cancel-in-progress: true

Fix

That is the setting working. For deploys, use cancel-in-progress: false so a running deploy finishes.

This run was waiting, and a newer run replaced it. Only one run waits per group, even with cancel-in-progress: false.

Check

gh run list --workflow <file>.yml --limit 5   # a newer run in the same group started after this one

Fix

Nothing to fix: the newest change is deployed; for deploys that is usually what you want.

The group name is too broad (no branch in it), so runs on unrelated branches cancel each other.

Check

grep -n 'group:' .github/workflows/*.yml   # no github.ref in the group

Fix

Include the branch: group: ${{ github.workflow }}-${{ github.ref }}.

No required reviewer has approved yet.

Check

gh api repos/<owner>/<repo>/actions/runs/<run-id>/pending_deployments   # the environment and who can approve

Fix

Approve from the run page (or the API) as a required reviewer; pending deployments expire after 30 days.

The person who could approve is the one who started the run, and Prevent self-review is on.

Check

gh api repos/<owner>/<repo>/environments/production --jq '.protection_rules[] | select(.type == "required_reviewers")'   # prevent_self_review true

Fix

Ask another reviewer to approve.

The repository is not checked out yet, so the workspace is empty.

Check

grep -n -B6 'uses: ./' .github/workflows/<file>.yml   # no actions/checkout before it

Fix

Run actions/checkout first.

The path is wrong. It is relative to the workspace root and must start with ./.

Check

ls .github/actions/setup   # in a step: action.yml exists?

Fix

Use the path from the repository root starting with ./

checkout used path:, so the repository is in a subfolder of the workspace.

Check

grep -n -A3 'actions/checkout' .github/workflows/<file>.yml   # path: set

Fix

Include that folder in uses: (./src/.github/actions/setup), or check out to the root.

A run step in the composite action has no shell: key.

Check

grep -n -B1 -A2 'run:' .github/actions/*/action.yml   # a run step without shell:

Fix

Add shell: bash to each run step in action.yml.

The called workflow does not list the secret under on.workflow_call.secrets.

Check

grep -n -A8 workflow_call .github/workflows/deploy.yml   # DEPLOY_TOKEN missing under secrets:

Fix

Declare the secret in the called workflow, or use secrets: inherit.

The names differ in spelling between caller and called workflow.

Check

grep -n -A4 'secrets:' .github/workflows/*.yml   # compare the names on both sides

Fix

Use the same name on both sides.

The uses: path is wrong. It must be owner/repo/.github/workflows/file.yml@ref, or ./.github/workflows/file.yml in the same repository.

Check

gh api 'repos/<owner>/<repo>/contents/.github/workflows/build.yml?ref=main' --jq .path   # 404: no such file at that path

Fix

Correct the path.

The ref after @ does not exist.

Check

git ls-remote https://github.com/<owner>/<repo> '<ref>'   # nothing printed: no such branch or tag

Fix

Use an existing tag or commit SHA.

The called workflow is in a private or internal repository that does not allow access from this one.

Check

gh api repos/<owner>/<repo> --jq .visibility   # private or internal: check its Settings > Actions > General > Access

Fix

In the called repository, allow access under Settings > Actions > General > Access.

The file has no on: workflow_call, so it is not reusable (the message then says is not reusable as it is missing).

Check

grep -n -A3 workflow_call .github/workflows/build.yml   # nothing printed

Fix

Add on: workflow_call: to the called file.