Skip to content
Nasir Nasir-Ameen
Notes

Confidential fintech platform

CI failed before tests because the environment was too clean

A Turbo strict-environment pipeline exposed variables that local dotenv loading had been hiding.
5 min read

A test suite that passed on every developer machine failed in CI before a single test ran. The backend refused to start because required configuration was missing.

Why it worked locally

Locally, configuration came from a file that is loaded automatically, so every variable the backend validates at startup was simply present. Nobody had to think about which task needed which variable.

In CI, the build tool was running tasks in strict mode. In that mode a task only receives the environment variables that have been declared for it. Anything undeclared is removed before the task starts.

So the variables existed in CI. The test task was just never given them.

The tempting fix

Turning strict mode off would have made the pipeline pass. It would also have put back the hidden dependency that caused the confusion: tasks quietly relying on whatever happens to be set.

The fix I made

I declared, for each task, the variables it really needs, and gave the test job safe placeholder values where it needs the shape of the configuration but not a live service.

After that, the full test command ran every task and all 900 tests passed.

Why I was glad it failed

A task that inherits its whole environment can depend on something by accident, and nobody finds out until it runs somewhere cleaner. Strict mode turns that into a contract: this task needs these values. The failure was the tool pointing at a dependency that had never been written down.

What I check now

When something passes locally and fails in CI before any real work starts, I compare what each environment gives the process before I look at the code.