-
Set up your environment (one-time).
-
Run
helpfor a list of release tool commands. -
After fixing a failure, use
workspace cleanupto reset state from the previous step.
Many steps use TLS. If a proxy or security tool adds trust anchors to the browser but not the JVM, Java may fail to connect; align trust with the JDK you use for the CLI, or turn off that interception while releasing.
The Pre-Release tasks and Post-Release tasks phases of making a release (opening and closing tickets) are locally ran tasks.
The Build and publish the release phase runs on the CI server.
flowchart LR
pre[PreReleaseTasks] --> ci[BuildAndPublish]
ci --> post[PostReleaseTasks]
post --> more{MoreReleases}
more -->|yes| pre
more -->|no| postAll[PostAllReleasesTasks]
-
Ensure all work on CVEs potentially contained in the release is done (incl. backports etc.).
-
Upgrade dependencies in Spring Data Build parent pom (mind minor/major version rules).
-
Review open tickets for release:
$ tracker open-tickets $trainIteration
-
Announce release preparations to the mailing list (https://groups.google.com/forum/#!forum/spring-data-dev).
-
Create the release tag, verify the release can be built, and publish tags:
$ prepare-it $trainIteration
-
π₯ Continue with Build and distribute the release.
| Action | Command |
|---|---|
Go to the Spring Data Release repository |
|
Start the |
Run workflow on |
-
For a Maven central release, if the smoke test has passed, the repository will already have been released, so there is nothing more to do.
-
For an Artifactory release, if the smoke test has passed, the release will already have been staged and promoted, so there is nothing more to do.
-
π₯ Continue with Post-Release tasks.
| Action | Command |
|---|---|
Close release tickets. |
|
Create new release versions and tickets for upcoming version |
|
-
π₯ Go to Pre-Release tasks to ship the next release π.
-
π₯ If this has been the last release π, continue with Post-All-Releases tasks for the final steps.
| Action | Command |
|---|---|
Update versions in the Projects Service. |
|
Create list of docs for release announcements |
|
Trigger Antora documentation build (once all artifacts have arrived at the final Maven repository) |
|
Announce release (Blog, Twitter) and notify downstream dependency projects as needed. |
N.A. |
Congratulations π₯³ You completed the release β€οΈ.
-
Ensure you have the credentials for
buildmasteraccounts on https://repo.spring.io.
Both are available in the Spring/Pivotal Last Pass repository.
-
Add an
application-local.propertiesfile in the project root with the following properties:-
git.username- Your GitHub username. -
git.password- Your GitHub Password (or API key with scopes:public_repo, read:org, repo:status, repo_deployment, userwhen using 2FA). -
git.author- Your full name (used for preparing commits). -
git.email- Your email (used for preparing commits). -
maven.mavenHome- Pointing to the location of your Maven installation. -
deployment.username- Your Artifactory user. -
deployment.api-key- The Artifactory API key to use for artifact promotion. -
deployment.password- The encrypted Artifactory password. -
gpg.keyname- The GPG key name. -
gpg.passphrase- The password of your GPG key. -
gpg.executable- Path to your GPG executable, typically/usr/local/MacGPG2/bin/gpg2or/usr/local/bin/gpg. -
project-service.key- Project Service authentication token. Must be a valid GitHub token. Can be the same asgit.passwordwhen using a GitHub token as password. Use the following scopes:project, read:org, repo, user, workflow.
-
(See application-local.template for details.)
-
Verify your local settings (authentication, correct Maven, Java, and GPG setup):
$ verify local
The Post-Release tasks and Post-All-Releases tasks sections list the tracker, documentation, projects service, and announcement commands you run after CI; they are not repeated in the table below.
| Action | Command |
|---|---|
All release tickets are present |
|
Self-assign release tickets |
|
Prepare the release |
|
|
|
|
|
Build the release |
|
Build the artifacts from tag and push them to the appropriate maven repository. Also runs smoke tests, does Sonatype "release" if applicable, and does Artifactory "promote" if applicable. |
|
Distribute documentation and static resources from tag |
|
Push the created commits to GitHub |
|
Push new maintenance branches if the release version was a GA release ( |
|
Java and Maven versions are installed via SDKman during the Dockerfile build. See ci/java-tools.properties for further details.
ProjectLabelConfiguration contains a per-project configuration which labels should be present in a project. To apply that configuration (create or update), use:
$ github update labels $project [--commercial]
ProjectDependencies contains a per-project configuration of dependencies.
To check for dependency upgrades:
$ dependency check $trainIteration
This generates two files that report upgradable dependencies for Spring Data Build and Spring Data modules, respectively:
-
dependency-upgrade-build.properties-
Edit this file to specify the dependencies and their corresponding version to upgrade. Removing a line will omit that dependency upgrade.
-
Update
dependency.upgrade.countvalue. -
Apply dependency upgrades to Spring Data Build:
$ dependency upgrade $trainIteration
-
-
dependency-upgrade-modules.properties-
Open a ticket for each dependency upgrade in the corresponding module (sample).
-
Report store-specific dependencies to Spring Bootβs current upgrade ticket (sample).
To generate a dependency report:
$ dependency report $trainIteration
To upgrade Maven across all modules:
-
Check for the latest stable Maven version.
$ infra maven check $trainIteration
-
This generates a
dependency-upgrade-maven.propertiesfile that reports an upgradable version of Maven Wrapper, if it exists.
-
-
Apply Maven upgrade across all modules.
$ infra maven upgrade $trainIteration
To distribute ci/pipeline.properties from Spring Data Build across all modules:
$ infra distribute ci-properties $trainIteration
To distribute .github/workflows/project.yml from Spring Data Build across all modules:
$ infra distribute gh-workflow $trainIteration
Note that your GitHub token to authenticate against GitHub must have the workflow permission.
Resolve external links in reference documentation and print their status.
$ docs check-links $trainIteration
Flags for docs check-links:
| Flag | Description |
|---|---|
--local |
read the documentation from disk (target module workspace directory) |
--project |
only check links of a specific project (eg. |
--report |
only report errors of the given categories (ERROR,REDIRECT,OK). Default is ALL |
$ docs check-links Turing GA --report ERROR
$ docs check-links Turing SR1 --local true --project redisResolve external links of any web page (remote/local) and print their status.
$ check-links $url
Flags for check-links:
| Flag | Description |
|---|---|
--report |
only report errors of the given categories (ERROR,REDIRECT,OK). Default is ALL |
$ check-links file:///usr/git/spring-data-mongodb/target/site/reference/html/index.html --report ERROR,REDIRECT$trainIteration-
Release train label passed to CLI commands and CI (for example
Turing GAor2022.0.1). $trainIteration.next-
Literal placeholder usgithub trigger-downstream-workflow --source-repository spring-data-commons --workflow snapshots.yml --head-branch 3.5.xed in commands such as
tracker setup-nextandgit pushfor the next train after the one you just shipped. $releaseTrains-
Comma-separated release-train code names with no spaces (for example
X,Y,T).