When GitHub Actions passes locally but fails in CI, compare runner, shell, env, and lockfile first

When GitHub Actions passes locally but fails in CI, compare runner, shell, environment, and lockfile before rewriting the code. A local pass proves only that one machine can run the command. It does not prove that the hosted job has the same operating system, shell behavior, event context, dependency graph, cache state, or secret availability.

GitHub Actions documents default environment variables, contexts, workflow reruns, job reruns, and debug logging. Those references are useful because they show how much of a workflow is evaluated from the run context rather than from the repository code alone. A failure can come from a matrix entry, branch ref, pull request event, changed working directory, missing token permission, expired cache, or a different package manager version.

A practical first pass is to collect the failing job name, commit SHA, runner image, shell, workflow trigger, matrix values, lockfile diff, install command, and exact command that failed. Then compare the local command with the CI command. If they differ, reproduce the CI command locally or in a clean container before changing application logic. If they match, inspect environment-only inputs such as secrets, paths, permissions, and event payload.

Rerunning can be valuable, especially with debug logging, but a rerun without a packet can hide the original clue. Keep the original log excerpt and the rerun result together. If the failure disappears, the evidence may point to cache, network, dependency resolution, or an intermittent external service rather than a deterministic code defect.

When GitHub Actions passes locally but fails in CI, compare runner, shell, env, and lockfile first

// COMMENTS

ON THIS PAGE