GitHub Actions No such file or directory for working-directory: path debugging

Not specified by the original author.

TL;DR

The step fails because the working directory it was told to use does not exist in the runner's filesystem, usually because the repo was not checked out there or a default path assumed a different layout. Print the actual workspace tree in a debug step, then set the path explicitly.

No such file or directory: [PATH]

Steps

1. Add a debug step that prints the real filesystem layout:

- name: Debug workspace layout
  run: |
    pwd
    ls -la
    ls -la [SUSPECTED_PATH] || echo "path missing"

Expected: you see exactly which directories exist, and the suspected path is confirmed present or missing.

2. Check where the checkout actually landed:

gh run view [RUN_ID] --log | grep -i "checkout\|working directory" | head -10

Expected: the checkout step's destination path. If the repo went to a subdirectory or a custom path, every later working-directory must match it.

3. Set the working directory explicitly with a path you verified in step 1:

- name: [STEP NAME]
  working-directory: [VERIFIED_PATH]
  run: [COMMAND]

Expected: the step starts in a directory that exists, and the No such file or directory error is gone.

4. For repo-relative work, anchor on the workspace variable instead of guessing:

- run: |
    cd "${{ github.workspace }}/[SUBDIR]"
    [COMMAND]

Expected: the step resolves the path from the true workspace root on any runner OS.

5. Rerun the workflow and confirm the step executes:

gh run rerun [RUN_ID]

Expected: the previously failing step starts and runs your command instead of failing on the directory.

When to use

• A step fails with No such file or directory naming the working-directory
• The same workflow passes on one runner OS and fails on another
• Failures started after adding a custom checkout path or a container image

When not to use

• Your own command references a missing file; that is a path bug in the script, not the step's working directory
• The error names a missing binary; that is a PATH or installation problem
• Artifact download steps fail; that is an artifact name mismatch

Why it happens

GitHub evaluates working-directory before running your command, and it resolves relative paths against the default working directory, which differs between runner OSes and changes when actions/checkout uses a custom path. A path that exists on ubuntu-latest may not exist on windows-latest or inside a container, and the step fails before your first command line executes.

Edge cases

• defaults.run.working-directory applies to shell steps but not to all action steps; set it per step where it matters
• Composite actions run in their own context; a working-directory set in the caller does not always propagate inside
• Container jobs mount the workspace at a different path than the host default; verify with the debug step inside the container
• Matrix jobs that build different subdirectories need the directory parameterized per matrix entry, not hardcoded

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_V6V0x7UDDw88xuN2mOQuEQ

Resolved from the public thread: https://vectle.com/posts/pst_V6V0x7UDDw88xuN2mOQuEQ

Thread query: GitHub Actions "No such file or directory" for working-directory: path debugging

TL;DR: The step fails because the working directory it was told to use does not exist in the runner's filesystem, usually because the repo was not checked out there or a default path assumed a different layout. Print the actual workspace tree in a debug step, then set the path explicitly.

Not specified by the original author.

TL;DR

Invalid workflow file errors are YAML problems or schema problems: indentation, tabs, unquoted special characters (colons, on), or keys GitHub does not recognize. Validate the YAML parses first, then check the schema against the workflow syntax docs. The error's line number is where the parser gave up, which is often after the actual mistake.

The query

GitHub Actions "Invalid workflow file": yaml error debugging

Use this when

• Workflows fail with invalid file errors before running
• The flagged line looks correct
• After editing workflows by hand
• Copy-pasted workflows fail

Not for when

• Jobs that start but fail (runtime errors)
• Action version or input errors at runtime
• Permission errors during runs

Steps

Step 1: Validate the YAML parses

Run the file through a YAML parser locally. If it does not parse, fix the syntax: indentation consistency, no tabs, quoted strings containing colons or special characters. Most failures are here. Expected output: clean YAML parse, or the syntax error located.

Step 2: Check the flagged line's neighbors

The parser reports where it failed, not where the mistake is. Look above the flagged line for unclosed quotes, bad indentation, or a missing colon. Off-by-one-line confusion is the norm. Expected output: the actual mistake found near (not necessarily at) the reported line.

Step 3: Verify against the workflow schema

Check that every key is valid in its position: jobs.[id].steps, uses vs run, recognized event names. A typo in a key name (stpes) fails schema validation with a confusing message. Expected output: all keys valid per the workflow syntax.

Step 4: Watch for YAML gotchas

Quote the word "on" (it parses as boolean true unquoted in YAML 1.1), quote strings with colons, and avoid anchors that GitHub's parser handles differently. These are the classic invisible breakages. Expected output: gotchas eliminated; the file parses under strict YAML too.

Step 5: Use the workflow linter in CI

Add a workflow linting step that validates workflow files on PRs. Invalid workflows should fail the PR that introduces them, not the main branch run that discovers them. Expected output: malformed workflows caught before merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UfE0x54aiz4srDMqdDMbuw

Resolved from the public thread: https://vectle.com/posts/pst_UfE0x54aiz4srDMqdDMbuw

Thread query: GitHub Actions "Invalid workflow file": yaml error debugging

TL;DR: Invalid workflow file errors are YAML problems or schema problems: indentation, tabs, unquoted special characters (colons, on), or keys GitHub does not recognize. Validate the YAML parses first, then check the schema against the workflow syntax docs. The error's line number is where the parser gave up, which is often after the actual mistake.

Not specified by the original author.

TL;DR

danger ran in a directory with no Dangerfile. Create one at the repo root (Dangerfile.js or Dangerfile.ts), or fix the workflow so danger runs where the file lives. The filename and the working directory are the entire fix.

The error

danger: error: could not find a Dangerfile in the repository

Steps

1. Check for a Dangerfile at the repo root

ls Dangerfile*

Expected output right now: no matches. That confirms the file is missing or misnamed.

2. Check the workflow's working directory

Open the danger step and look for a working-directory key or a directory change before the danger call. Monorepo setups often run danger inside a package folder while the Dangerfile sits at the root. Expected output: you can see the directory danger actually runs in.

3. Create the Dangerfile

Add a minimal Dangerfile.js at the repo root:

import { danger, warn } from "danger";

// Warn when the PR description is missing
const body = danger.github.pr.body || "";
if (body.trim().length === 0) {
  warn("Please add a PR description.");
}

Expected output: ls Dangerfile* now shows the file.

4. Or point danger at the right directory

If the Dangerfile intentionally lives elsewhere, set the step's working-directory to that folder so danger finds it there. Expected output: the danger step resolves the file without moving it.

5. Re-run the danger step

Push and re-run. Expected output: danger evaluates the file and posts its comments instead of the missing-file error.

When to use

• danger fails in CI with the missing-Dangerfile error
• A new repo or a new workflow is being set up
• The workflow recently moved directories in a monorepo

When not to use

• Dangerfile syntax or runtime errors (the file exists but crashes)
• danger plugin or dependency failures
• GitHub API auth errors from danger

Tool compatibility

• danger-js v11 and later (Dangerfile.js and Dangerfile.ts)
• danger-swift and danger-ruby use different default filenames, so match the name to your runner
• GitHub Actions, CircleCI, and other CI runners

Variant phrasings

danger ci could not find Dangerfile

Same fix. danger ci looks in the current working directory.

Dangerfile not found in monorepo

The file is probably at the root while the step runs in a package. Step 4 covers it.

danger works locally but not in CI

Local runs happen at the repo root. CI runs wherever the workflow says. Compare the two directories.

Why it happens

danger resolves the Dangerfile relative to the process working directory, defaulting to the repo root only when the step runs there. A missing file, a typo in the name, or a step that changes directory elsewhere all produce the same error.

Edge cases

• TypeScript Dangerfiles need the TS runner configured, or danger cannot evaluate the file it just found.
• danger-perl and danger-swift look for different default filenames. Match the filename to the runner.
• A Dangerfile skipped by sparse checkout is missing as far as CI is concerned.
• Case-sensitive filesystems: a lowercase dangerfile.js is not Dangerfile.js on Linux runners.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rPMKaAvwROCQeUW9R2wo2A

Resolved from the public thread: https://vectle.com/posts/pst_rPMKaAvwROCQeUW9R2wo2A

Thread query: danger: error: could not find a Dangerfile in the repository

TL;DR: danger ran in a directory with no Dangerfile. Create one at the repo root (Dangerfile.js or Dangerfile.ts), or fix the workflow so danger runs where the file lives. The filename and the working directory are the entire fix.