Diagnose a failing CI pipeline

Find why a build or pipeline fails in CI but not locally, and get the exact change to fix it.

LLazyPrompt(@lazyprompt)CodingAnalyzeWorks with any model
No ratings yetSign in to rate
Save 0 Fork Report
Prompt template
My CI pipeline is failing. Help me find the cause and the fix.

CI system: {{ci}}
Project type and stack: {{stack}}
Does it pass locally?: {{local}}
What changed since the last green run: {{changes}}

Pipeline config:
{{config}}

Log output around the failure (include some lines before the first error):
{{log}}

Please:
1. Find the first real error in the log, ignoring the cascade of follow-on errors, and quote it. Say which step failed and why.
2. List the plausible causes ranked, considering differences between my machine and CI: clean checkout, cached dependencies, tool and OS versions, environment variables and secrets, file permissions and case sensitivity, available memory and time limits, network access, and test ordering.
3. For the top cause, give the exact config or code change as a diff, and a way to reproduce it locally (for example a container command that mimics the CI image).
4. Suggest how to confirm the fix without waiting for many full runs.
5. Point out any unrelated problems in the config that I should fix: missing cache keys, unpinned versions, steps that run twice, or unnecessary privileges.

If the log is cut off or the cause is ambiguous, tell me exactly what to add to the log or which debug flag to turn on.
Example output
**First real error:** step "Test" failed with `Cannot find module './Utils'` imported from `src/format.test.ts`. The following 40 errors are consequences. **Ranked causes** 1. File-name case mismatch (high). The file is `utils.ts`, the import says `./Utils`. macOS is case-insensitive, Linux CI is not, which also fits "passes locally on macOS". 2. Stale cache (low). Cache key ignores the lockfile, but the error is not dependency related. **Fix** ```diff - import { fmt } from "./Utils"; + import { fmt } from "./utils"; ``` Reproduce locally: ```bash docker run --rm -v "$PWD":/app -w /app node:20 sh -c "corepack enable && pnpm i --frozen-lockfile && pnpm test" ``` **Confirm quickly:** run only the failing test file in the container before pushing. **Other issues in the config** - The cache key is `deps-v1`; use `${{ hashFiles('pnpm-lock.yaml') }}`. - `pnpm install` runs in both the build and test jobs; share the install via cache. - Node version is `20`; pin it to a minor version for repeatable builds.

Why it works

Ranking differences between your machine and CI covers most real-world causes, and the container reproduction command saves many push-and-wait cycles. Paste more context lines for a surer diagnosis.

Licensed CC0 (public domain) Version 1 · history