Add scheduled CI job to auto-update testnet config settings JSON files

[leighmcculloch]

What problem does your feature solve?

The quickstart image contains hardcoded Soroban config settings in local/core/etc/config-settings/p{N}/testnet.json files. These are used when running in --local mode so that the local network has settings consistent with testnet without needing to contact the outside world.

These files frequently drift out of date because they require manual PRs to update. This has been a recurring maintenance burden, with multiple PRs over the past years doing nothing but updating these values:

• Add p26 settings files #901 — Add p26 settings files (Feb 2026)
• Fix settings to match testnet #733 — Fix settings to match testnet (Aug 2025)
• Update testnet settings config for p23 #716 — Update testnet settings config for p23 (Jul 2025, draft, never merged)
• Update core to 20.3.0 #578 — Update testnet.json to match stellar-core (Mar 2024)
• Update Soroban network settings files to reflect recent changes #536 — Update Soroban network settings files to reflect recent changes (Dec 2023)

Issue #715 proposed adding a test that checks whether the settings are up-to-date with testnet. PR #545 attempted to pull settings directly from stellar-core at build time but went stale. Neither was completed.

What would you like to see?

Add a scheduled GitHub Actions workflow (e.g. weekly) that:

1. Queries the current Soroban config settings from testnet (e.g. via stellar-cli or via RPC and a script using the stellar-xdr to encode to json)
2. Compares them against the current testnet.json file(s) for the latest protocol version in local/core/etc/config-settings/
3. If they differ, opens a PR automatically with the updated testnet.json

This would also serve as the detection mechanism requested in #715, since a PR being opened signals drift.

What alternatives are there?

• Test-only (as in Add test that checks testnet config settings are up-to-date with testnet #715): A CI check that fails when settings drift, requiring a human to manually create the update PR. Simpler but still requires manual work.
• Build-time fetch (as in Pull settings file from stellar-core #545): Pull settings from stellar-core repo at Docker build time. Risk: changes to the source file path/format in stellar-core would break quickstart builds.
• Runtime fetch: Have the quickstart container fetch settings from testnet at startup. Breaks the offline/hermetic use case that the hardcoded file exists to support.

Related

• Add test that checks testnet config settings are up-to-date with testnet #715 — Add test that checks testnet config settings are up-to-date with testnet (open)
• Pull settings file from stellar-core #545 — Pull settings file from stellar-core (closed/stale)
• Two step upgrade #734 — Two step upgrade (made future updates easier by allowing exact testnet settings paste)
• Fix settings to match testnet #733 — Fix settings to match testnet
• Add p26 settings files #901 — Add p26 settings files