|
1 | 1 | # GitHub Actions Workflows for Spring Projects
|
2 | 2 |
|
3 | 3 | This project containers reusable GitHub Actions Workflows to build Spring projects with Gradle or Maven.
|
4 |
| -SNAPSHOT and Release workflows uses JFrog CLI to publish artifacts into Artifactory. |
| 4 | +The workflows are designed for specific tasks and can be reused individually or in combinations in the target projects. |
5 | 5 |
|
6 |
| -The `spring-artifactory-release.yml` must be used like this in the target workflow: |
| 6 | +To use these workflows in your project a set of organization secrets must be granted to the repository: |
7 | 7 | ```
|
8 |
| -name: Release |
9 |
| -
|
10 |
| -on: |
11 |
| - workflow_dispatch: |
12 |
| -
|
13 |
| -run-name: Release current version for branch ${{ github.ref_name }} |
14 |
| -
|
15 |
| -jobs: |
16 |
| - release: |
17 |
| - uses: artembilan/spring-messaging-build-tools/.github/workflows/spring-artifactory-release.yml@main |
18 |
| - with: |
19 |
| - buildToolArgs: dist |
20 |
| - verifyStagedWorkflow: verify-staged-artifacts.yml |
21 |
| - secrets: |
22 |
| - GH_ACTIONS_REPO_TOKEN: ${{ secrets.GH_ACTIONS_REPO_TOKEN }} |
23 |
| - GRADLE_ENTERPRISE_CACHE_USER: ${{ secrets.GRADLE_ENTERPRISE_CACHE_USER }} |
24 |
| - GRADLE_ENTERPRISE_CACHE_PASSWORD: ${{ secrets.GRADLE_ENTERPRISE_CACHE_PASSWORD }} |
25 |
| - GRADLE_ENTERPRISE_SECRET_ACCESS_KEY: ${{ secrets.GRADLE_ENTERPRISE_SECRET_ACCESS_KEY }} |
26 |
| - JF_ARTIFACTORY_SPRING: ${{ secrets.JF_ARTIFACTORY_SPRING }} |
27 |
| - SPRING_RELEASE_SLACK_WEBHOOK_URL: ${{ secrets.SPRING_RELEASE_SLACK_WEBHOOK_URL }} |
28 |
| - OSSRH_URL: ${{ secrets.OSSRH_URL }} |
29 |
| - OSSRH_S01_TOKEN_USERNAME: ${{ secrets.OSSRH_S01_TOKEN_USERNAME }} |
30 |
| - OSSRH_S01_TOKEN_PASSWORD: ${{ secrets.OSSRH_S01_TOKEN_PASSWORD }} |
31 |
| - OSSRH_STAGING_PROFILE_NAME: ${{ secrets.OSSRH_STAGING_PROFILE_NAME }} |
32 |
| - GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }} |
33 |
| - GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }} |
| 8 | +GH_ACTIONS_REPO_TOKEN |
| 9 | +GRADLE_ENTERPRISE_CACHE_USER |
| 10 | +GRADLE_ENTERPRISE_CACHE_PASSWORD |
| 11 | +GRADLE_ENTERPRISE_SECRET_ACCESS_KEY |
| 12 | +JF_ARTIFACTORY_SPRING |
| 13 | +SPRING_RELEASE_SLACK_WEBHOOK_URL |
| 14 | +OSSRH_URL |
| 15 | +OSSRH_S01_TOKEN_USERNAME |
| 16 | +OSSRH_S01_TOKEN_PASSWORD |
| 17 | +OSSRH_STAGING_PROFILE_NAME |
| 18 | +GPG_PASSPHRASE |
| 19 | +GPG_PRIVATE_KEY |
34 | 20 | ```
|
35 |
| -on every branch which is supposed to be released via GitHub actions. |
| 21 | + |
| 22 | +The Gradle Enterprise secrets are optional: not used by Maven and Gradle project might not be enrolled for the service. |
| 23 | + |
| 24 | +The mentioned secrets must be passed explicitly since these reusable workflows might be in different GitHub org than target project. |
| 25 | + |
| 26 | +The SNAPSHOT and Release workflows uses JFrog CLI to publish artifacts into Artifactory. |
| 27 | + |
| 28 | +## Build SNAPSHOT and Pull Request Workflows |
| 29 | + |
| 30 | +The `[spring-gradle-pull-request-build.yml](.github%2Fworkflows%2Fspring-gradle-pull-request-build.yml)` and `[spring-maven-pull-request-build.yml](.github%2Fworkflows%2Fspring-maven-pull-request-build.yml)` are straight forward, single job reusable workflows. |
| 31 | +They perform Gradle `check` task and Maven `verify` goal, respectively. |
| 32 | +The caller workflow is as simple as follows. |
| 33 | + |
| 34 | +Gradle Pull Request caller workflow: |
| 35 | +./samples/pr-build-gradle.yml |
| 36 | + |
| 37 | +Maven Pull Request caller workflow: |
| 38 | +./samples/pr-build-maven.yml |
| 39 | + |
| 40 | +You can add more branches to react for pull request events. |
| 41 | + |
| 42 | +The SNAPSHOT workflows (`[spring-artifactory-gradle-snapshot.yml](.github%2Fworkflows%2Fspring-artifactory-gradle-snapshot.yml)` and `[spring-artifactory-maven-snapshot.yml](.github%2Fworkflows%2Fspring-artifactory-maven-snapshot.yml)`, respectively) are also that simple. |
| 43 | +They use JFrog CLI action to be able to publish artifacts into `libs-snapshot-local` repository. |
| 44 | +The Gradle workflow can be supplied with Gradle Enterprise secrets. |
| 45 | + |
| 46 | +Gradle SNAPSHOT caller workflow: |
| 47 | +./samples/ci-snapshot-gradle.yml |
| 48 | + |
| 49 | +Maven SNAPSHOT caller workflow: |
| 50 | +./samples/ci-snapshot-maven.yml |
| 51 | + |
| 52 | +## Release Workflow |
| 53 | + |
| 54 | +The `[spring-artifactory-release.yml](.github%2Fworkflows%2Fspring-artifactory-release.yml)` workflow is complex enough, has some branching jobs and makes some assumptions and expects particular conditions on your repository: |
| 55 | + |
| 56 | +- 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. |
| 57 | +For example: `0.0.1-SNAPSHOT`, `1.0.0-M1`, `2.1.0-RC2`, `3.3.3`. |
| 58 | +- GitHub Milestone titles must be exact as the version to release number. |
| 59 | +For example: `1.0.0-M1`, `2.1.0-RC2`, `3.3.3`. |
| 60 | +- GitHub Milestones must be scheduled: have a `Due on` date set. |
| 61 | +Otherwise, release workflow will be cancelled with a warning that nothing to release for respective SNAPSHOT in a branch. |
| 62 | + |
| 63 | +The logic of this release workflow: |
| 64 | + |
| 65 | +- Take a SNAPSHOT version from a dispatched branch (Maven `help:evaluate -Dexpression="project.version"` and Gradle `gradle properties | grep "^version:"`, respectively) |
| 66 | +- List GitHub milestones matching the candidate version and select the closest one by due on date |
| 67 | +- Cancel workflow if no scheduled Milestone |
| 68 | +- Call Maven or Gradle according to the project (essentially, it tests for `pom.xml` file presence) with the release version extracted from the previous job. |
| 69 | +This job stages released artifacts using JFrog CLI into `libs-staging-local` repository on Spring Artifactory and commits `Next development version` to the branch we are releasing against |
| 70 | +- The next job is to [verify staged artifacts](#verify-staged-artifacts) |
| 71 | +- When verification is successful, next job promotes release from staging either to `libs-milestone-local` or `libs-release-local`(and Maven Central) according to the releasing version schema |
| 72 | +- Then `[spring-finalize-release.yml](.github%2Fworkflows%2Fspring-finalize-release.yml)` job is executed, which generates release notes using [Spring Changelog Generator](https://github.com/spring-io/github-changelog-generator) excluding repository admins from `Contributors` section. |
| 73 | +The `gh release create` command is performed on a tag for just released version. |
| 74 | +And in the end the milestone is closed and specific Slack channel is notified about release. |
| 75 | + |
| 76 | +Example of Release caller workflow: |
| 77 | +./samples/release.yml |
| 78 | + |
| 79 | +Such a workflow must be on every branch which is supposed to be released via GitHub actions. |
36 | 80 |
|
37 | 81 | The `buildToolArgs` parameter for this job means extra build tool arguments.
|
38 | 82 | For example, the mentioned `dist` value is a Gradle task in the project.
|
39 | 83 | Can be any Maven goal or other command line arguments.
|
40 | 84 |
|
41 |
| -The mentioned secrets must be passed explicitly since these reusable workflows might be in different GitHub org than target project. |
| 85 | +## Verify Staged Artifacts |
42 | 86 |
|
43 |
| -When a release workflow is dispatched, the `releaseVersion` job determines the milestone to release against the current SNAPSHOT version in the branch. |
44 |
| -If no milestone scheduled, the whole workflow is cancelled. |
45 | 87 | Then `staging` job uses the `releaseVersion` output from the previous `releaseVersion` job and dispatch the work to Gradle or Maven jobs according to the project build tool.
|
46 | 88 | The `verify-staged` expects an optional `verifyStagedWorkflow` input (the `verify-staged-artifacts.yml`, by default) workflow supplied from the target project.
|
47 |
| -For example, [Spring Integration for AWS](https://github.com/spring-projects/spring-integration-aws) use `jfrog rt download` command to verify that released `spring-integration-aws.jar` is valid. |
| 89 | +For example, [Spring Integration for AWS](https://github.com/spring-projects/spring-integration-aws) use `jfrog rt download` command to verify that released `spring-integration-aws-${{ inputs.releaseVersion }}.jar` is valid. |
48 | 90 | Other projects may check out their samples repository and setup release version to perform smoke tests against just staged artifacts.
|
49 | 91 |
|
50 |
| -The next job in the workflow is to promote release from staging either to `libs-milestone-local` or `libs-release-local`(and Maven Central) according to the releasing version schema. |
| 92 | +Verify staged workflow sample: |
| 93 | +./samples/verify-staged-artifacts.yml |
51 | 94 |
|
52 |
| -After promotion, the `finalize` job is executed, which generates release notes using [Spring Changelog Generator](https://github.com/spring-io/github-changelog-generator) excluding repository admins from `Contributors` section. |
53 |
| -Then the `gh release create` command is performed on a tag for just released version. |
54 |
| -And in the end the milestone is closed and specific Slack channel is notified about release. |
| 95 | +## Gradle and Artifactory |
55 | 96 |
|
56 | 97 | Gradle projects must not manage `com.jfrog.artifactory` plugin anymore: the `jf gradlec` command sets up this plugin and respective tasks into a project using JFrog specific Gradle init script.
|
57 |
| -In addition, the `spring-artifactory-gradle-snapshot.yml` and `spring-artifactory-gradle-release-staging.yml` add `spring-project-init.gradle` script to provide an `artifactory` plugin settings for artifacts publications. |
| 98 | +In addition, the `[spring-artifactory-gradle-snapshot.yml](.github%2Fworkflows%2Fspring-artifactory-gradle-snapshot.yml)` and `[spring-artifactory-gradle-release-staging.yml](.github%2Fworkflows%2Fspring-artifactory-gradle-release-staging.yml)` add `spring-project-init.gradle` script to provide an `artifactory` plugin settings for artifacts publications. |
58 | 99 | This script also adds a `nextDevelopmentVersion` task which is used when release has been staged and job is ready to push `Next development version` commit.
|
0 commit comments