this post was submitted on 13 Jul 2026
20 points (100.0% liked)

Programming

27689 readers
335 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev
20
What do you check first when a CI pipeline passes locally but fails in CI? (lemmy.world)
submitted 17 hours ago by indidev@lemmy.world to c/programming@programming.dev
9 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
[โ€“] stsquad@lemmy.ml 2 points 12 hours ago

In QEMU all of our CI environments are replicable locally as docker/podman images. However usually flaky CI is due to races exposed on overloaded runners so I often also run make -j(nproc) at the same time to simulate that. A retry script is also useful to get an idea of how stable a test is. Having sanitizer builds can also help.