This project contains reusable GitHub Actions Workflows to build Spring projects with Gradle or Maven. And provides some other useful utilities to perform from GitHub Actions, such a Dependabot auto-merge, or automatic back-port issue creation.
The workflows are designed for specific tasks and can be reused individually or in combinations in the target projects.

To use these workflows in your project a set of organization secrets must be granted to the repository:

GH_ACTIONS_REPO_TOKEN
DEVELOCITY_ACCESS_KEY
JF_ARTIFACTORY_SPRING
ARTIFACTORY_USERNAME
ARTIFACTORY_PASSWORD
SPRING_RELEASE_CHAT_WEBHOOK_URL
NOTIFICATIONS_CHAT_WEBHOOK_URL
CENTRAL_TOKEN_USERNAME
CENTRAL_TOKEN_PASSWORD
GPG_PASSPHRASE
GPG_PRIVATE_KEY

The Develocity secret is optional: mostly not used by Maven, and a Gradle project might not be enrolled for the service.
The SPRING_RELEASE_CHAT_WEBHOOK_URL secret is also optional: probably you don't want to notify Google Space about your release, or it is not available for GitHub organization. The NOTIFICATIONS_CHAT_WEBHOOK_URL secret is also optional: when set, the CI, SNAPSHOT and cherry-pick workflows send a Google Chat notification whenever their job fails. As well as CENTRAL_TOKEN_* secrets, since not all releases might go to Maven Central Portal, e.g. private (commercial) repositories only.

The mentioned secrets must be passed explicitly since these reusable workflows might be in a different GitHub org than the target project.

The SNAPSHOT and Release workflows use spring-io/artifactory-deploy-action to publish artifacts into Artifactory.

The spring-gradle-pull-request-build.yml and spring-maven-pull-request-build.yml are straight forward, single job reusable workflows. They perform Gradle check task and Maven verify goal, respectively. The caller workflow is as simple as follows.

You can add more branches to react to pull request events.

The SNAPSHOT workflows (spring-artifactory-gradle-snapshot.yml and spring-artifactory-maven-snapshot.yml, respectively) are also that simple. They publish artifacts into libs-snapshot-local (by default) repository. The Gradle workflow can be supplied with Develocity secret.

Both Gradle and Maven SNAPSHOT build workflow requires ARTIFACTORY_USERNAME & ARTIFACTORY_PASSWORD secretes to authorise spring-io/artifactory-deploy-action. Optionally, all the artifacts can be signed if GPG_PASSPHRASE and GPG_PRIVATE_KEY secrets are provided.

The spring-artifactory-gradle-release.yml (and therefore spring-artifactory-maven-release.yml) workflow is complex enough, has some branching jobs and makes some assumptions and expects particular conditions on your repository:

• The versioning schema must follow these rules: 3-digit-dotted number for major, minor and patch parts, snapshot is suffixed with -SNAPSHOT, milestones are with -M{number} and -RC{number} suffix, the GA release is without any suffix. For example: 0.0.1-SNAPSHOT, 1.0.0-M1, 2.1.0-RC2, 3.3.3.
• GitHub Milestone titles must be exact as the version-to-release number. For example: 1.0.0-M1, 2.1.0-RC2, 3.3.3.
• GitHub Milestones must be scheduled: have a Due on date set. Otherwise, the release workflow will be cancelled with a warning that nothing to release for the respective SNAPSHOT in a branch.

The logic of this release workflow:

• Take a SNAPSHOT version from a dispatched branch (Maven help:evaluate -Dexpression="project.version" and Gradle gradle properties | grep "^version:", respectively).
• List GitHub milestones matching the candidate version and select the closest one by due on date. (The spring-find-release-version reusable workflow is implemented for this goal)
• Cancel workflow if no scheduled Milestone
• Call Maven or Gradle (according to the workflow choice for the project in the repository) with the release version extracted from the previous job. This job stages released artifacts using JFrog Artifactory plugin into libs-staging-local repository on Spring Artifactory and commits Next development version to the branch we are releasing against
• The next job is to verify staged artifacts
• When verification is successful, next job promotes release from staging either to libs-milestone-local or libs-release-local (by default) (and optional to Maven Central: if bundleName input is not provided) according to the releasing version schema
• Then spring-finalize-release.yml job is executed, which tags the release into GitHub, commits the next development version, and pushes both the commit and the new v{milestone} tag to the branch we are releasing against.

That tag push is itself the trigger for spring-post-release.yml: a separate, push: tags-triggered workflow (not part of the job graph above) which generates release notes using Spring Changelog Generator excluding repository admins from the Contributors section, creates the GitHub release for that tag, closes the milestone, updates the spring.io project page for the newly released version (via the spring-website-project-version-update local action), notifies the configured Google Space (if SPRING_RELEASE_CHAT_WEBHOOK_URL secret is present), and computes/creates the next scheduled milestone. It derives the milestone (and whether it's a hotfix) straight from the pushed tag name, so it reacts identically no matter who pushed the tag - spring-finalize-release.yml above, or some other process (e.g. a release train orchestrator publishing this project's version into the repository). For any release that isn't a hotfix and isn't already end-of-life (including -M/-RC previews), it also merges the pushed release tag back into the corresponding {major}.{minor}.x maintenance branch. Falls back to the repository's default branch if that branch doesn't exist yet - so the tag's commit isn't left stranded unreachable from any branch. Then commits its own next-SNAPSHOT version bump on top, since the tag itself carries no such commit when it was pushed by a release train orchestrator rather than spring-finalize-release.yml. Hotfix branches are excluded: they're one-time-use and never continued from.

Wire it up once per repository, alongside your release caller workflow:

name: Post Release

on:
  push:
    tags:
      - 'v*'

jobs:
  post-release:
    uses: spring-io/spring-github-workflows/.github/workflows/spring-post-release.yml@main
    secrets:
      GH_ACTIONS_REPO_TOKEN: ${{ secrets.GH_ACTIONS_REPO_TOKEN }}
      SPRING_RELEASE_CHAT_WEBHOOK_URL: ${{ secrets.SPRING_RELEASE_GCHAT_WEBHOOK_URL }}

Such a workflow must be on every branch that is supposed to be released via GitHub actions.

The buildToolArgs parameter for this job means extra build tool arguments. For example, the mentioned dist value is a Gradle task in the project. Can be any Maven goal or other command line arguments.

The signing released artifacts is done by the spring-io/artifactory-deploy-action if GPG_PASSPHRASE and GPG_PRIVATE_KEY secrets are provided. In the end, all the artifacts, together with their signatures, are uploaded to the Artifactory according to the respective workflow inputs.

In the end you just need to go to the Actions tab on your project, press Run workflow on your release workflow and choose a branch from a drop-down list to release currently scheduled Milestone against. Such a release workflow can also be scheduled (cron, for example) against branches matrix.

Warning The spring-artifactory-gradle-release.yml (and spring-artifactory-maven-release.yml) already uses 3 of 4 levels of nested reusable workflows. Where the caller workflow is the last one. Therefore don't try to reuse your caller workflow.

The verify-staged job expects an optional verifyStagedWorkflow input (the verify-staged-artifacts.yml, by default) workflow supplied from the target project. For example, Spring Integration for AWS uses jfrog rt download command to verify that released spring-integration-aws-${{ inputs.releaseVersion }}.jar is valid. Other projects may check out their samples repository and set up release version to perform smoke tests against just staged artifacts.

The spring-backport-issue.yml uses Spring Backport Bot to create a back-port issue according to the event configured in a caller workflow. See its documentation for labeling convention and respective GitHub events for calling this workflow.

If Dependabot is enabled for the repository, its config should set a label compatible with Spring Changelog Generator. Typically, it is type: dependency-upgrade. It is also a good practice to group all the development dependencies into a single pull request from Dependabot. This includes all the Gradle and Maven plugins and those dependencies which are used only for testing in the project. This project provides a spring-merge-dependabot-pr.yml reusable workflow to make modifications to the Dependabot pull requests. However, there are some prerequisites to use this workflow in your project:

• Pull requests must be protected by some check to pass, usually a workflow to build the project with these pull request changes;
• The auto-merge must be enabled in the repository (if --auto is used);

The spring-merge-dependabot-pr workflow does these modifications to the Dependabot pull requests:

• Modify label from dependency-upgrade to the task for the development dependencies group update to skip them from release notes by Spring Changelog Generator;
• Adds a currently scheduled milestone to the pull request against a snapshot version extracted from the target branch;
• And if a milestone is scheduled, the pull request is queued for auto-merging after required checks have passed;
• If autoMergeSnapshots input is set to true, the upgrade from Milestone/Release Candidate dependency to its SNAPSHOT is going to be merged automatically without assigning a milestone to the PR.

The mergeArguments input of this workflow is applied to the gh pr merge command.

The spring-cherry-pick.yml workflow offers a logic to cherry-pick pushed commits to branches suggested by the specific sentence in each commit message. Every commit in the push is considered, not just the last one. For example Auto-cherry-pick to 6.2.x & 6.1.x. The Auto-cherry-pick token is a default value for the autoCherryPickToken input of this workflow. The branches to cherry-pick to are extracted from the matching sentence. The "Auto-cherry-pick" sentence is removed from the target commit message. The -x option of git cherry-pick command adds a link back to the original commit. Force-pushes (e.g. a rebase) are skipped entirely, and any commit whose patch is already present on the target branch is skipped as well, to avoid replaying cherry-picks that were already performed. Re-runs of this workflow are cancelled: a failed cherry-pick needs a manual fix pushed by hand, not a retry of the same automated logic.

The spring-announce-milestone-planning.yml workflow offers an automatic chat message publishing when due_on on the repository milestone is changed. The callers workflow must be configured like this:

name: Announce Milestone Planning in Chat

on:
  milestone:
    types: [ created, edited ]

jobs:
  announce-milestone-planning:
    uses: spring-io/spring-github-workflows/.github/workflows/spring-announce-milestone-planning.yml@main
    secrets:
      SPRING_RELEASE_CHAT_WEBHOOK_URL: ${{ secrets.SPRING_RELEASE_GCHAT_WEBHOOK_URL }}

The workflow reacts to non-empty due_on property of the event's milestone payload and check if this property really was changed on milestone edit.

The spring-trigger-dependabot-updates.yml workflow is a convenient alternative to the GitHub UI interface for Dependabot updates ($GH_REPOSITORY/network/updates). The workflow performs toggle executable permission as a superficial change on the dependabot.yml file. That is enough for Dependabot to understand that some changes have happened in the dependency updates config to trigger new versions check.

The spring-dispatch-workflow-and-wait action implements the logic to call gh workflow run for the provided workflow file and wait until it is complete, successful or not. This action is used in the verify-staged job of the release workflow.

The Gradle Build Actionand a script with Maven repository for publishing artifacts into a local directory (/deployment-repository) via respective publishAllPublicationsToDeploymentRepository Gradle task. Then spring-io/artifactory-deploy-action picks up those artifacts for uploading to the Artifactory. The Maven build does that via deploy goal and respective -DaltDeploymentRepository=local::file:deployment-repository CLI option.

See more information in the Reusing Workflows.