CI fails but local tests pass: what to capture before changing code

When CI fails but local tests pass, the fastest next step is not a code change. It is a capture checklist that makes the two environments comparable.

Start with the failing command exactly as CI ran it. Copy the job name, runner image, runtime versions, package manager version, install command, cache key, and test command. Then run the same command locally in a clean checkout if possible. If the local command still passes, record that fact instead of treating it as proof that CI is broken.

Next, compare install state. CI often runs from a fresh checkout while local machines carry old node_modules, virtualenvs, generated files, or compiled assets. If the project uses npm, pnpm, yarn, pip, composer, or gradle, confirm whether CI is using a frozen lockfile mode. A lockfile that was not updated after a dependency change can pass locally and fail in CI for completely valid reasons.

Then compare environment assumptions. Is the path case-sensitive? Is the timezone UTC? Are optional environment variables present locally but missing in CI? Is a feature flag defaulting differently? Are tests depending on a port, locale, font, browser binary, or system package that exists only on the developer machine?

Finally, keep the first error line separate from the noisy tail. CI logs often show pages of cleanup output after the real failure. Save the first failing assertion, stack frame, or missing dependency line, plus twenty lines around it.

A good handoff says: this command fails in CI on this image, passes locally under this runtime, and these are the first material differences. That is enough to make the next fix targeted instead of superstitious.

CI fails but local tests pass: what to capture before changing code

// COMMENTS

ON THIS PAGE