feat(local-cre): runtime CRE-settings override helper for e2e tests

[prashantkumar1982]

What

Adds a test helper — helpers.ApplyCRESettings(t, env, overrides) — that overrides CRE settings on a DON at runtime, without restarting the topology, and restores the pre-test baseline on cleanup. Plus scope-varied smoke tests (global / org / workflow / multi-scope) demonstrating apply and cleanup.

Why

Today, exercising a settings/flag change in a Local CRE e2e test means tearing down the topology and starting a new one with the flag baked into CL_CRE_SETTINGS. This lets a test flip settings inline, scoped to that test, and revert automatically — the same delivery path prod uses (the cre-settings durable-pipeline job proposed to all nodes).

How it works

• A node applies settings live when it receives a cresettings job: the delegate calls loop.AtomicSettings.Store, which hot-swaps the in-memory settings getter (no restart). See core/services/cresettings/delegate.go.
• The helper reuses the existing deployment changeset (ProposeJobSpec{Template: CRESettings}) to propose that job to every node of the target DON, then approves it on each node. Approve only returns once all nodes accepted — so a successful call means the whole DON converged (no split-brain).
• Overrides are merged onto the DON's boot CL_CRE_SETTINGS baseline (each Store fully replaces the getter, so a bare diff would drop boot settings) and rendered as a scoped TOML doc ([global] / [org.<id>] / [owner.<id>] / [workflow.<id>], string values).
• Cleanup re-applies the baseline (deleting the job does not revert), via a t.Cleanup and/or an explicit Handle.Reset(t).

Files

• system-tests/tests/test-helpers/cresettings_override.go — the helper (ApplyCRESettings, CRESettingsOverrides, Handle{Reset,AppliedTOML,BaselineTOML}).
• system-tests/tests/smoke/cre/cresettings_override_test.go — Test_CRE_CRESettings_Override_{Global,Org,Workflow,MultiScope}.
• core/scripts/cre/environment/docs/cresettings-runtime-override-proposal.md — design write-up (mechanism, live-vs-restart classification, gotchas).

Testing

• ✅ Compiles/links against develop (go test -c ./system-tests/tests/smoke/cre), go vet clean, go mod tidy applied.
• ⏳ Not yet run end-to-end (needs a live Local CRE env). Run with the env up:

  go test ./system-tests/tests/smoke/cre -run '^Test_CRE_CRESettings_' -timeout 20m -v
  

Notes for review

• Live-vs-restart: per-execution limits/gates flip immediately; rate/queue limits within ~5s; but registration-time settings (trigger subscription limits, WASM size checks, workflow admission) only affect workflows registered after the override — flip those before deploying the workflow.
• Illustrative IDs: the org/workflow IDs in the tests are placeholders; real tests pass the actual IDs from deployment.
• Assumption: tests target the DON named workflow (default topology). Not parallelized — they mutate shared-DON settings, so they run serially and revert promptly.

🤖 Generated with Claude Code

[github-actions]

✅ No conflicts with other open PRs targeting develop

[trunk-io]

   

Failed Test	Failure Summary	Logs
Test_CRE_CRESettings_Override_Global	The test failed because it attempted to approve a job proposal that was already approved, causing an error.	Logs ↗︎
Test_CRE_CRESettings_Override_Workflow	The test failed during a configuration override application, with multiple nodes reporting failed proposals for setting updates.	Logs ↗︎
Test_CRE_CRESettings_Override_Org	The test failed due to errors in applying configuration overrides and proposals for multiple nodes.	Logs ↗︎
Test_CRE_CRESettings_Override_MultiScope	The test failed during a configuration override application, indicating an issue with job proposal validation or execution.	Logs ↗︎

View Full Report ↗︎ ⋅ Docs

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube