This project containers reusable GitHub Actions Workflows to build Spring projects with Gradle or Maven. 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
OSSRH_S01_TOKEN_USERNAME
OSSRH_S01_TOKEN_PASSWORD
OSSRH_STAGING_PROFILE_NAME
GPG_PASSPHRASE
GPG_PRIVATE_KEYThe Develocity secret is optional: not used by Maven and 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.
As well as OSSRH_* secret, since not all releases might go to Maven Central, e.g. private (commercial) repositories only.
The mentioned secrets must be passed explicitly since these reusable workflows might be in different GitHub org than target project.
The SNAPSHOT and Release workflows uses JFrog Artifactory plugin 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 for pull request events.
The SNAPSHOT workflows (spring-artifactory-gradle-snapshot.yml and spring-artifactory-maven-snapshot.yml, respectively) are also that simple.
They use JFrog Artifactory plugin to be able to publish artifacts into libs-snapshot-local (by default) repository.
The Gradle workflow can be supplied with Gradle Enterprise secrets.
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:
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.1.0.0-M1, 2.1.0-RC2, 3.3.3.Due on date set.
Otherwise, release workflow will be cancelled with a warning that nothing to release for respective SNAPSHOT in a branch.The logic of this release workflow:
help:evaluate -Dexpression="project.version" and Gradle gradle properties | grep "^version:", respectively).libs-staging-local repository on Spring Artifactory and commits Next development version to the branch we are releasing againstlibs-milestone-local or libs-release-local (by default) (and optional to Maven Central: if OSSRH_STAGING_PROFILE_NAME secret is provided) according to the releasing version schemaContributors section.
The gh release create command is performed on a tag for just released version.
Then spring.io project page is updated for newly released version.
(The spring-website-project-version-update local action is implemented for this goal).
And in the end the milestone closed and specific Google Space notified about release (if SPRING_RELEASE_CHAT_WEBHOOK_URL secret is present in the repository).Such a workflow must be on every branch which 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 drop-down list to release currently scheduled Milestone against.
Such a release workflow can also be scheduled (cron, fo 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 setup 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 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 projects 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:
--auto is used);The spring-merge-dependabot-pr workflow does these modifications to the Dependabot pull requests:
dependency-upgrade to the task for the development dependencies group update to skip them from release notes by Spring Changelog Generator;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 commit to branches suggested by the specific sentence in commit message.
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 remove from the target commit message.
The -x option of git cherry-pick command adds a link back to the original commit.
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-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 [deployment-repository-init.gradle](utils/deployment-repository-init.gradle) script adds a 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.