Replace release-ci-settings.xml with maven-settings-action repository config

[ryanjbaxter]

Summary

Replace the release-ci-settings.xml file that is added to commercial release branches with s4u/maven-settings-action inputs in deploy.yml, so the commercial repository configuration is written to ~/.m2/settings.xml at runtime instead of being committed to the branch.

Not actionable yet — projects are mid-release using release-ci-settings.xml today. This is tracked for after those releases complete.

Motivation

Commercial release branches (release/<version> and the new <major>.<minor>.x-internal branches) get two files added during initialization by add-commercial-release-files: ci-release.yml and release-ci-settings.xml. The design goal is to avoid modifying any existing file so the branch merges back into the OSS repo cleanly.

release-ci-settings.xml still puts a file in the repo, which means:

• spring-release-train-project-ready has to delete it before the release is finalised
• it appears in branch history that later merges back to OSS
• every build command has to carry --settings release-ci-settings.xml
• deploy.yml detects "this is a commercial release branch" by sniffing for the file (if [[ -f "release-ci-settings.xml" ]]), which couples an unrelated concern to a file's existence

deploy.yml already runs s4u/maven-settings-action to write ~/.m2/settings.xml. At the currently pinned SHA (894661b3ddae382f1ae8edbeab60987e08cf0788) that action supports servers, repositories, pluginRepositories and mirrors — everything release-ci-settings.xml provides.

Proposed change

Map the contents of config/release-ci-settings.xml onto the action's inputs:

release-ci-settings.xml	Action input
5 <server> entries (commercial + the repo.spring.io alias)	servers (already used, extend it)
4 <repository> entries in the spring profile	repositories
4 <pluginRepository> entries	pluginRepositories

Then:

• stop adding release-ci-settings.xml in add-commercial-release-files
• drop --settings release-ci-settings.xml (MAVEN_SETTINGS) from the build commands
• remove the release-ci-settings.xml deletion step from spring-release-train-project-ready
• delete config/release-ci-settings.xml

Deploy targeting is unaffected — that is altSnapshotDeploymentRepository (MAVEN_DEPLOY_FLAGS), not settings.

Open questions to resolve during implementation

1. Replacement trigger. deploy.yml currently keys off the presence of release-ci-settings.xml to decide whether to apply commercial release settings. With the file gone this needs an explicit signal — most likely a commercial_release: true input passed from the generated ci-release.yml, which is clearer than sniffing for a file.

2. Profile scoping changes. Today the commercial repos live inside <profile id="spring"> and only apply when -Pspring is active. s4u/maven-settings-action writes repositories into a profile it activates unconditionally, so they would be visible to every Maven invocation in the job. Probably fine, but it is a behavioral difference. The OSS spring-snapshots repo must remain reachable — commercial Artifactory does not carry OSS snapshots.

3. Backward compatibility. Branches created before this change will still have release-ci-settings.xml committed. deploy.yml should keep honouring the file for some transition period so in-flight release branches keep building.

Out of scope

This does not enable delegating to a project's own CI workflow (e.g. spring-cloud-kubernetes's maven.yaml with its sharded test matrix). s4u/maven-settings-action runs as a step and only affects Maven invocations in the same job, so a called reusable workflow running on a fresh runner is unaffected. That would still require editing the project's maven.yaml or .mvn/maven.config.