-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt GHA Scala Library Release Workflow #44
Conversation
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. 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: * `scmInfo` & `pomExtra` * `homepage` * `developers` * `releasePublishArtifactsAction` * `publishTo` * Remove the 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 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 . This change also drops support for Scala 2.11 since it does not seem to support the -release:11 scalac option which is required to ensure that the Java 17 workflow produces Java 11 compatible bytecode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NB - PR description liberally copied from guardian/facia-scala-client#299
😄
- Grant this repo access to the GitHub Organisation Secrets containing the Maven Release credentials with Grant
facia-scala-client
the Maven Release creds github-secret-access#21
You'll need to make your own PR in guardian/github-secret-access
- I don't see tags-thrift-schema
in there yet!
Apart from the points noted, this looks great, thank you for doing this!
As far as testing goes, the best way to test is just merge this PR, and then run the release process on the main
branch - if the release run crashes out, it's not the end of the world, we can just fix the problems.
This repo should probably also be added to Scala Steward as well, but that can happen later.
.github/workflows/release.yml
Outdated
release: | ||
uses: guardian/gha-scala-library-release-workflow/.github/workflows/reusable-release.yml@main | ||
permissions: | ||
contents: write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is missing one permission - see the example release.yml
referenced by the docs at configuration.md#github-workflow
(guardian/gha-scala-library-release-workflow#19 introduced an extra required permission)
build.sbt
Outdated
resolvers += Resolver.jcenterRepo | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably worth removing this resolver if you can get away with it, due to the security concerns recently christened MavenGate
!
resolvers += Resolver.jcenterRepo |
Co-authored-by: Roberto Tyley <[email protected]>
Co-authored-by: Roberto Tyley <[email protected]>
Co-authored-by: Roberto Tyley <[email protected]>
mainly to get license.apache2 constant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks good to me - once merged, test it out by performing a release!
I can see you had a
This is because guardian/gha-scala-library-release-workflow#5 is not yet resolved, but I'm working on it in guardian/gha-scala-library-release-workflow#26 - in the meantime, as mentioned in configuration.md#repo-settings, you should disable Branch Protection on the main branch - as mentioned in guardian/gha-scala-library-release-workflow#5 (comment), DevX are fine with this - edit, oh, I can see you already have! |
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.
The changes required to adopt the automated workflow:
scmInfo
&pomExtra
homepage
developers
releasePublishArtifactsAction
publishTo
releaseProcess
configuration, because the workflow does those now, and the workflow only wantssbt release
to create the versioning commits, and tag them appropriately. The workflow does the rest itself.sbt-pgp
plugin because it's no longer used - the workflow does the signing usinggpg
directly.Additionally, we add automatic version numbering based on compatibility assessment performed by
sbt-version-policy
:sbt-version-policy
plugin, to allow it to do the compatibility assessment. This also sets theversionScheme
for this library toearly-semver
, which is the recommended versioning for Scala libraries, andsbt-version-policy
& correct sbt-eviction-issue-detection pretty much depend on theversionScheme
beingearly-semver
. Thus we also need to switch to using a new semver version number for our library version!releaseVersion := fromAggregatedAssessedCompatibilityWithLatestRelease().value
sbt setting, which will intelligently set the release version based onsbt-version-policy
's compatibility assessment, thanks to Simplify integration with sbt-release scalacenter/sbt-version-policy#187 .This change also drops support for Scala 2.11 since it does not seem to support the -release:11 scalac option which is required to ensure that the Java 17 workflow produces Java 11 compatible bytecode.
NB - PR description liberally copied from guardian/facia-scala-client#299