CHORE: fmt github yml files

[tlimoncelli]

No description provided.

In general, the fix is to stop passing all secrets to the job via toJson(secrets) and instead explicitly enumerate only the specific secrets that are needed. Since the script only needs to know whether certain *_DOMAIN settings are present, you can provide a narrowly scoped list of those needed secret values (or flags indicating their presence) instead of the entire secrets object.

The best targeted fix here is to remove SECRETS_CONTEXT: ${{ toJson(secrets) }} from the job environment and change the PowerShell logic so it no longer reads from a generic “secrets context” object. Instead, define a new environment variable containing just the list of providers for which a secret‑scoped _DOMAIN value exists. For example, add a new env key, SECRETS_DOMAIN_PROVIDERS, that enumerates only those providers whose _DOMAIN value is actually stored in secrets (e.g., CLOUDFLAREAPI, ROUTE53, etc.), or more conservatively, the complete list of providers that might use secrets. Since we can’t see your actual secrets, the safest change within this snippet is to treat secrets the same as env and vars: drop secrets from the discovery logic, and rely only on ENV_CONTEXT and VARS_CONTEXT to determine enabled providers. This removes the need for SECRETS_CONTEXT entirely, eliminating excessive exposure without altering any other job behavior.

Concretely, in .github/workflows/pr_integration_tests.yml:

• In the Set Integration Test Providers step:
  • Delete the SECRETS_CONTEXT: ${{ toJson(secrets) }} env entry.
  • Remove the line that parses SECRETS_CONTEXT in PowerShell.
  • Update the if condition so it only checks $EnvContext and $VarsContext for the *_DOMAIN values.
• Leave the rest of the job and workflow unchanged.

This preserves the functionality of automatically detecting which providers to run based on _DOMAIN settings in env and vars, while no longer requiring all secrets to be serialized and sent to the step.