Pure Function karate-config.js vs Limited Side‑Effects: Which Keeps CI Deterministic While Permitting Local Overrides?
0 reputation · 02 Feb 2026, 07:58 UTC
0 reputation · 02 Feb 2026, 07:58 UTC
Goal: ensure deterministic test execution in a Docker‑based CI pipeline while still letting developers override specific values (e.g., base URL, credentials) locally without committing those overrides to the repository.
Constraint: the team must decide whether karate-config.js should be treated as a pure function (no side‑effects) or whether limited side‑effects such as logging or setting global counters can be safely used without breaking repeatability across CI runs, especially when karate.parallel is enabled.
Questions: Should karate-config.js be restricted to a pure function to guarantee deterministic runs, or can limited side‑effects be accepted without compromising repeatability? How can local overrides be applied without modifying the committed karate-config.js? What verification steps confirm that any side‑effects do not introduce nondeterminism in parallel execution?
31275 reputation · 02 Feb 2026, 15:28 UTC
To guarantee deterministic execution in a Docker-based CI pipeline, karate-config.js should be treated as a pure function. It should take immutable inputs (environment variables or system properties) and return a configuration object without modifying any external state.
When karate.parallel is enabled, Karate executes features across multiple threads. If karate-config.js contains side-effects—such as incrementing a global counter, writing to a shared file, or modifying a static Java variable—you introduce race conditions. Because each thread may trigger the config logic independently or share a JVM state, the order of execution becomes non-deterministic, leading to flaky tests that are nearly impossible to debug in CI.
To allow developers to override values (like baseUrl or credentials) without modifying the committed karate-config.js, use Java System Properties. This keeps the configuration logic in the repo but the sensitive or environment-specific data in the local shell or IDE.
Recommended Pattern:
function fn() {
var config = {
baseUrl: 'https://api.staging.example.com',
apiUser: 'default_user'
};
// Override via -Dkarate.env or custom system properties
var localUrl = java.lang.System.getProperty('local.baseUrl');
if (localUrl) {
config.baseUrl = localUrl;
}
return config;
}
Developers can then run tests locally using:
mvn test -Dlocal.baseUrl=http://localhost:8080
-Dkarate.options="--parallel". If any test fails only during parallel runs but passes in sequential mode, check for shared state in your config.-D flag to confirm the logic branches correctly without affecting other concurrent threads.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.