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
[–] 4 points 3 months ago

I use mise-en-place for this same sort of thing. Many of my shared workflows demand a certain contract be satisfied including things like providing artifact coordinates, mise tasks (build, publish, etc.). One can also use mise to specify the runtime versions to simplify local build and test and ci using the same runtimes.

Of course, there is no best solution, since this is a "how long is a piece of string" sort of question.

  • permalink
  • fedilink
  • source
  • parent