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

[prashantkumar1982]

What

Adds a test helper — helpers.ApplyCRESettings(t, env, opts...) — 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.

Scopes are passed as functional options, each carrying that scope's settings TOML (no scope prefix); compose several in one call to apply them together:

h := helpers.ApplyCRESettings(t, env,
    helpers.Global(`[PerWorkflow.HTTPAction]
CallLimit = '11'`),
    helpers.Org(orgID, `[PerOrg]
BaseTriggerRetransmitEnabled = 'false'`),
    helpers.Workflow(workflowID, `[PerWorkflow]
ExecutionConcurrencyLimit = '1'`),
)
// ...auto-reverts on t.Cleanup, or call h.Reset(t) to revert early

Global, Org(id, …), Owner(id, …), Workflow(id, …), and FromFS(fs.FS) (for on-disk fixtures) are the available options.

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 worker node of the target DON(s) (bootstrap-gateway DONs have no worker/plugin nodes and are skipped). Nodes auto-approve cresettings jobs on proposal, so delivery is propose-only.
• The options build a prod-style file tree combined by the deployment CombineCRESettingsFiles — the same code that produces the compiled settings.toml — into a scoped TOML doc ([global] / [org.<id>] / [owner.<id>] / [workflow.<id>], string values). Overrides are merged onto each DON's boot CL_CRE_SETTINGS baseline (each Store fully replaces the getter, so a bare diff would drop boot settings).
• Cleanup re-applies the baseline (deleting the job does not revert), via a t.Cleanup and/or an explicit Handle.Reset(t).
• A single-active-override guard keeps these tests honest: overrides mutate the shared environment, so a second override — from a concurrent test, or from the same test applying again before reverting — is refused with an actionable error. Re-apply within one test by calling Reset(t) first, or compose all scopes in one call.

See the usage guide: core/scripts/cre/environment/docs/cresettings-override-README.md.

[github-actions]

✅ No conflicts with other open PRs targeting develop

[trunk-io]

   

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