Repository navigation
Replace release-ci-settings.xml with maven-settings-action repository config #5
Description
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-readyhas 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.ymldetects "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.xmlinadd-commercial-release-files - drop
--settings release-ci-settings.xml(MAVEN_SETTINGS) from the build commands - remove the
release-ci-settings.xmldeletion step fromspring-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
-
Replacement trigger.
deploy.ymlcurrently keys off the presence ofrelease-ci-settings.xmlto decide whether to apply commercial release settings. With the file gone this needs an explicit signal — most likely acommercial_release: trueinput passed from the generatedci-release.yml, which is clearer than sniffing for a file. -
Profile scoping changes. Today the commercial repos live inside
<profile id="spring">and only apply when-Pspringis active.s4u/maven-settings-actionwrites 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 OSSspring-snapshotsrepo must remain reachable — commercial Artifactory does not carry OSS snapshots. -
Backward compatibility. Branches created before this change will still have
release-ci-settings.xmlcommitted.deploy.ymlshould 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.
Activity
ryanjbaxter commentedon Aug 14, 2026
New dependency: project repos now detect
release-ci-settings.xmlby nameSince this issue was written,
spring-cloud-kubernetesgained aMAVEN_SETTINGSmechanism in itsenv-variablescomposite that selects a Maven settings file by filename:Every
./mvnwinvocation in that project'smaven.yamland its composites uses$MAVEN_SETTINGS. This is what lets the5.0.x-internalbranch reuse the project's own sharded test pipeline without modifying any existing file — the whole reason the file-based approach was kept there.Impact on this issue: deleting
release-ci-settings.xmlfrom the branch makes that first branch fall through to.settings.xml, which carries only the OSS repositories. The build would then fail to resolve-INTERNAL-SNAPSHOTdependencies, and the failure would look like a credentials problem rather than a missing repository.This is a silent fallback — no error, just the wrong settings file — so it needs handling as part of the same change, not afterwards.
What needs to happen alongside
spring-cloud-kubernetes'senv-variablescomposite (OSSmain, then bring into5.0.x-internal) so it no longer expectsrelease-ci-settings.xml. Ifdeploy.ymlwrites the commercial repositories into~/.m2/settings.xmlvias4u/maven-settings-action, the composite's Maven calls need the same treatment — note that the action writes user settings, so it only affects the job it runs in, andmaven.yaml's jobs would each need it.spring-cloud-kubernetesis the only one of the eleven-internalbranches with a bespoke pipeline; the other ten use the generatedci-release.ymland are unaffected.Sequencing
The two repos have to move together, or
5.0.x-internalbreaks in the window between them. Landing the composite change first — tolerating either source of settings — makes the switch safe to do in either order.