Replace release-ci-settings.xml with maven-settings-action repository config · Issue #5 · spring-cloud/spring-cloud-github-actions · GitHub
Skip to content

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

Open
Open
Replace release-ci-settings.xml with maven-settings-action repository config#5
Assignees
ryanjbaxter

Description

@ryanjbaxter
ryanjbaxter
opened on Aug 1, 2026

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.

Activity

  1. ryanjbaxter
    self-assigned this
    on Aug 1, 2026

  2. ryanjbaxter commented on Aug 14, 2026

    @ryanjbaxter
    ryanjbaxter
    on Aug 14, 2026
    ContributorAuthor

    New dependency: project repos now detect release-ci-settings.xml by name

    Since this issue was written, spring-cloud-kubernetes gained a MAVEN_SETTINGS mechanism in its env-variables composite that selects a Maven settings file by filename:

    if [[ -f "$GITHUB_WORKSPACE/release-ci-settings.xml" ]]; then
  echo "MAVEN_SETTINGS=-s $GITHUB_WORKSPACE/release-ci-settings.xml" >> $GITHUB_ENV
elif [[ -f "$GITHUB_WORKSPACE/.settings.xml" ]]; then
  echo "MAVEN_SETTINGS=-s $GITHUB_WORKSPACE/.settings.xml" >> $GITHUB_ENV
else
  echo "MAVEN_SETTINGS=" >> $GITHUB_ENV
fi

    Every ./mvnw invocation in that project's maven.yaml and its composites uses $MAVEN_SETTINGS. This is what lets the 5.0.x-internal branch 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.xml from 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-SNAPSHOT dependencies, 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

    1. Update spring-cloud-kubernetes's env-variables composite (OSS main, then bring into 5.0.x-internal) so it no longer expects release-ci-settings.xml. If deploy.yml writes the commercial repositories into ~/.m2/settings.xml via s4u/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, and maven.yaml's jobs would each need it.
    2. Check whether any other project has picked up the same pattern by then. As of 2026-08-14, spring-cloud-kubernetes is the only one of the eleven -internal branches with a bespoke pipeline; the other ten use the generated ci-release.yml and are unaffected.

    Sequencing

    The two repos have to move together, or 5.0.x-internal breaks in the window between them. Landing the composite change first — tolerating either source of settings — makes the switch safe to do in either order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions