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?
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.