-
Notifications
You must be signed in to change notification settings - Fork 6
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 #232
Conversation
Some projects output both Scala and NPM libraries with a single release - for example, we need to support this in content-api-models: guardian/content-api-models#232 ...rather than try to teach gha-scala-library-release-workflow how to do NPM releases, it seems better to let the workflow do the Scala release, and then output the release version number so that it can be used by a subsequent custom 'npm release' stage of caller workflow. See also: https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
ecab2f3
to
e0dba48
Compare
e0dba48
to
d7be5bd
Compare
lazy val npmPreviewReleaseTagMaybe = if (sys.env.get("RELEASE_TYPE").contains("PREVIEW_FEATURE_BRANCH")) { | ||
Seq(scroogeTypescriptPublishTag := "preview") | ||
} else Seq.empty |
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.
The NPM docs say "Other than latest
, no tag has any special significance to npm itself."
...so we can tag things as preview
, snapshot
, or beta
, as we like, and as the Scala workflow is producing PREVIEW
releases, it makes sense, I think, to keep the NPM tag the same.
case v if v == snapshotReleaseType => | ||
scroogeTypescriptPublishTag := "snapshot" | ||
}.toSeq | ||
lazy val npmPreviewReleaseTagMaybe = if (sys.env.get("RELEASE_TYPE").contains("PREVIEW_FEATURE_BRANCH")) { |
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.
Note that the RELEASE_TYPE
is coming from the environment variable supplied by release.yml
:
content-api-models/.github/workflows/release.yml
Lines 32 to 35 in b48291c
sbt "project typescript" "releaseNpm ${{ needs.scala-maven-release.outputs.RELEASE_VERSION }}" | |
env: | |
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} | |
RELEASE_TYPE: ${{ needs.scala-maven-release.outputs.RELEASE_TYPE }} |
The value of RELEASE_TYPE
could be either PREVIEW_FEATURE_BRANCH
or FULL_MAIN_BRANCH
, as determined by gha-scala-library-release-workflow
(see also guardian/gha-scala-library-release-workflow#19)
@rtyley has published a preview version of this PR with release workflow run #42, based on commit 6d00eca: 18.1.0-PREVIEW.adopt-GHA-Scala-Library-Release-Workflow.2024-01-23T1754.6d00eca6 Note from Roberto:This was a fun one - if you look at commit 6d00eca, you'll see that it is a pretty silly change, just used for double-checking that the NPM artifact released in a PREVIEW release was indeed based on the commit it claimed to be based on. I've now removed commit 6d00eca, as we definitely wouldn't want to merge that! |
97c5f49
to
e2d23aa
Compare
@rtyley has published a preview version of this PR with release workflow run #45, based on commit e2d23aa: 18.0.1-PREVIEW.adopt-GHA-Scala-Library-Release-Workflow.2024-01-24T1623.e2d23aa4 Want to make another preview release?Click 'Run workflow' in the GitHub UI, specifying the adopt-GHA-Scala-Library-Release-Workflow branch, or use the GitHub CLI command: gh workflow run release.yml --ref adopt-GHA-Scala-Library-Release-Workflow Want to make a full release after this PR is merged?Click 'Run workflow' in the GitHub UI, leaving the branch as the default, or use the GitHub CLI command: gh workflow run release.yml |
46a290c
to
20570f1
Compare
This is just prior to the main work of #232
20570f1
to
b48291c
Compare
This change adopts `gha-scala-library-release-workflow` for publishing releases, replacing some of the work done in PR #229 and providing some improvements: * Automatic version-numbering based on automated compatibility-assessment by sbt-version-policy * Standardisation with the other projects across the Guardian that have also adopted the workflow * Reduced configuration (fewer sbt settings, and less workflow yaml) This specific commit only provides Scala Maven release, removing NPM release capability, but NPM release capability is returned in the next commit.
This is in addition to the Scala Maven release provided by the previous commit. This change is only separated out from the previous commit to show how the 'standard' release.yml has been modified for this dual Scala & Typescript release workflow. This is a first for gha-scala-library-release-workflow - so far that workflow has only been used for publishing Scala projects to Maven - but the earlier work done in PR #229 supported automated release to both Maven and NPM (for NPM, we're talking Typescript artifacts generated from Thrift by scrooge-extras), and so it was important to continue to that support. Rather than teach the gha-scala-library-release-workflow reusable-release.yml how to publish NPM artifacts, it was easier to just modify the standard release.yml workflow that calls reusable-release.yml, adding an additional NPM Release workflow job after the Maven release process.
b48291c
to
d037761
Compare
Looks good! Nice to have the workflow handling npm and maven together :) |
Thankyou @rtyley for adding NPM release too in Details in PR description are great to understand. 👍 |
Thanks both! After merging, I ran a standard full release on the default |
…s-scala Now that guardian/content-api-models#232 has been merged and https://github.com/guardian/content-api-models/releases/tag/v18.0.1 has been released, the content-api-models models now declare themselves to adhere to 'early-semver' - and even more than that, thanks to sbt-version-policy, they actually _do_ adhere to it! This should mean that it is **no longer possible** for a single project that depends on content-api-scala-client & content-api-models to have _incompatible_ versions of those artifacts - sbt will reject the incompatibility **at compile time**, where it can be fixed by just ensuring that all libraries (eg including facia-scala-client) have all been compiled against the same versions: https://www.scala-lang.org/blog/2021/02/16/preventing-version-conflicts-with-versionscheme.html This should prevent horrible runtime errors like guardian/facia-scala-client#301 which occurred with the rollout of the innocent-looking changes in https://github.com/guardian/facia-scala-client/releases/tag/v4.0.6 .
This change adopts
gha-scala-library-release-workflow
for publishing releases of this library, replacing some of the work done in PR #229 and providing some improvements:sbt-version-policy
Changes to UX
beta
-suffixed release would be made for Scala libraries only.main
branch (a full release) or on a PR feature branch (a 'preview' release). Releases are always made for both Scala and Typescript libraries, but if this is a preview release, the NPM package will have an NPM tag ofpreview
rather thanlatest
.Releasing Maven and NPM artifacts
This is a first for
gha-scala-library-release-workflow
- so far this workflow has only been used for publishing Scala projects to Maven - but the earlier work done in PR #229 supported automated release to both Maven and NPM (for NPM, we're talking Typescript artifacts generated from Thrift byscrooge-extras
), and so it was important to continue to that support.Rather than teach the
gha-scala-library-release-workflow
reusable-release.yml
how to publish NPM artifacts, it was easier to just modify the standard release.yml workflow that calls reusable-release.yml, adding an additionalNPM Release
workflow job after the Maven release process:This uses some of the code from PR #229, and we've verified that it continues to successfully publish a
@guardian/content-api-models
to NPM with a PREVIEW release.