Adopt GHA Scala Library Release Workflow #208
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the 3rd library to adopt https://github.com/guardian/gha-scala-library-release-workflow, a new automated library release process that allows releases to be published to Maven Central with the click of a button. The changes in here are similar to the ones in guardian/play-secret-rotation#416, with the addition that sbt settings that provide the pom metadata required by Maven Central ( https://central.sonatype.org/publish/requirements/#project-name-description-and-url ) can be simplified thanks to the functionality provided by xerial/sbt-sonatype#58 - setting `sonatypeProjectHosting` takes care of a lot the fields!
rtyley
added a commit
to guardian/gha-scala-library-release-workflow
that referenced
this pull request
Dec 7, 2023
rtyley
added a commit
to guardian/facia-scala-client
that referenced
this pull request
Dec 13, 2023
Recent prior example of adding `gha-scala-library-release-workflow` to a repo: guardian/play-googleauth#208
rtyley
added a commit
to guardian/facia-scala-client
that referenced
this pull request
Dec 13, 2023
Recent prior example of adding `gha-scala-library-release-workflow` to a repo: guardian/play-googleauth#208
rtyley
commented
Dec 13, 2023
Comment on lines
+12
to
+13
| AUTOMATED_MAVEN_RELEASE_PGP_SECRET: ${{ secrets.AUTOMATED_MAVEN_RELEASE_PGP_SECRET }} | ||
| AUTOMATED_MAVEN_RELEASE_SONATYPE_PASSWORD: ${{ secrets.AUTOMATED_MAVEN_RELEASE_SONATYPE_PASSWORD }} |
There was a problem hiding this comment.
These GitHub Organisation Secrets are granted to this repo by https://github.com/guardian/github-secret-access/pull/18.
rtyley
added a commit
to guardian/facia-scala-client
that referenced
this pull request
Dec 13, 2023
This replaces the old release process which had developers manually running `sbt release` on their own laptops - each developer had to obtain their own PGP key and Sonatype credentials, which was an elaborate & fiddly process. Now there's a single set of release credentials, available through GitHub Organisation Secrets, like we already have with NPM. ### Required changes The changes required to adopt the automated workflow: * No need to set these sbt configuration keys, as they're now taken care of by the workflow: * `sonatypeProfileName` * `publishTo` * `scmInfo` & `pomExtra` * Remove the sign, publish, release & push steps of sbt-release's `releaseProcess` configuration, because the workflow does those now, and the workflow only wants `sbt release` to create the versioning commits, and tag them appropriately. The workflow does the rest itself. * Remove `sbt-pgp` plugin because it's no longer used - the workflow does the signing using `gpg` directly. * Grant this repo access to the GitHub Organisation Secrets containing the Maven Release credentials with guardian/github-secret-access#21 * Unusually, drop running the tests as part of the release for now, as the tests in this project require special credentials (see #272) Additionally, we add **automatic version numbering** based on compatibility assessment performed by `sbt-version-policy`: * Add the `sbt-version-policy` plugin, to allow it to do the compatibility assessment. This also sets the `versionScheme` for this library to `early-semver`, which is the recommended versioning for Scala libraries, and `sbt-version-policy` & correct sbt-eviction-issue-detection pretty much depend on the `versionScheme` being `early-semver`. Thus we also need to switch to using a new semver version number for our library version! * Add the `releaseVersion := fromAggregatedAssessedCompatibilityWithLatestRelease().value` sbt setting, which will intelligently set the release version based on `sbt-version-policy`'s compatibility assessment, thanks to scalacenter/sbt-version-policy#187 . * Use `publish / skip := true`, rather than other hacks like `publish := {}` or `publishArtifact := false`, to tell sbt not to publish modules that we don't want published (typically, the 'root' module) - this is important because `sbt-version-policy` won't understand those hacks, but _will_ understand `publish / skip := true` means that it doesn't need to assess compatibility there. Recent prior example of adding `gha-scala-library-release-workflow` to a repo: guardian/play-googleauth#208
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the 3rd library to adopt
gha-scala-library-release-workflow, a new automated library release process that allows releases to be published to Maven Central with the click of a button.The changes in here are similar to the ones in guardian/play-secret-rotation#416, with the addition that the sbt settings that provide the pom metadata required by Maven Central are simplified thanks to the functionality provided by xerial/sbt-sonatype#58 - setting
sonatypeProjectHostingtakes care of a lot the fields!