24
What do you check first when a CI pipeline passes locally but fails in CI? (lemmy.world)
submitted 3 months ago by to c/programming@programming.dev
11 comments fedilink hide all child comments
 

Been dealing with this more often lately. Tests pass on my machine, I push, and CI blows up. Usually it's one of these:

  • Different Node/Python/whatever version
  • Missing env vars that exist in my .env but not in CI secrets
  • File system case sensitivity (macOS vs Linux)
  • Some flaky test that depends on timing

My current debugging flow is pretty basic: check the logs, compare versions, run the exact same Docker image locally if I can. But it still eats 20-30 minutes each time before I figure out the actual problem.

Anyone have a more systematic approach? Like a quick checklist you run through before you even look at the logs?

Also curious — do you replicate your CI environment locally with something like act (for GitHub Actions) or just trust the remote runner?

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 3 months ago*

Usually, when CI fails, it's a flaky CI failure or that I have in fact not run it locally.

I guess some context is missing. My build flow seems much simpler. I check the CI steps overview and step log, and then I know what's wrong. That doesn't take 20 min. More like ~3 min.

At work, we use Jenkins and the runners are owned infrastructure. If I debug what goes wrong in the CI environment, I go into the pipeline definition, and do the calls locally, just like that, on the command line. No need for complicated environment replication beyond that. dotnet restore, dotnet build --no-restore, dotnet package --no-build, dotnet test --no-build, etc.

If it's not CI specific, issues show up in the normal local tooling without special env prep.

  • permalink
  • fedilink
  • source
    •