Skip to content
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

Merged
merged 3 commits into from
Jan 25, 2024

Conversation

rtyley
Copy link
Member

@rtyley rtyley commented Jan 19, 2024

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:

  • 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) - we deleted a lot of lines! ✨
    image

Changes to UX

  • Before: Developers would initiate a release by creating a Git tag with their choice of version number, and creating a GitHub Release with that tag. If the GitHub Release was 'pre-release', a beta-suffixed release would be made for Scala libraries only.
  • After: Developers run the release workflow, selecting whether they want to run it on the default 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 of preview rather than latest.

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 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:

image

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.

rtyley added a commit to guardian/gha-scala-library-release-workflow that referenced this pull request Jan 19, 2024
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
@rtyley rtyley force-pushed the adopt-GHA-Scala-Library-Release-Workflow branch 3 times, most recently from ecab2f3 to e0dba48 Compare January 23, 2024 16:48
rtyley added a commit to guardian/gha-scala-library-release-workflow that referenced this pull request Jan 23, 2024
@rtyley rtyley force-pushed the adopt-GHA-Scala-Library-Release-Workflow branch from e0dba48 to d7be5bd Compare January 23, 2024 17:27
Comment on lines +138 to +140
lazy val npmPreviewReleaseTagMaybe = if (sys.env.get("RELEASE_TYPE").contains("PREVIEW_FEATURE_BRANCH")) {
Seq(scroogeTypescriptPublishTag := "preview")
} else Seq.empty
Copy link
Member Author

@rtyley rtyley Jan 23, 2024

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")) {
Copy link
Member Author

@rtyley rtyley Jan 23, 2024

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:

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)

Copy link

github-actions bot commented Jan 23, 2024

@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!

@guardian guardian deleted a comment from github-actions bot Jan 24, 2024
@guardian guardian deleted a comment from github-actions bot Jan 24, 2024
@guardian guardian deleted a comment from github-actions bot Jan 24, 2024
@rtyley rtyley force-pushed the adopt-GHA-Scala-Library-Release-Workflow branch 4 times, most recently from 97c5f49 to e2d23aa Compare January 24, 2024 16:22
Copy link

@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

@rtyley rtyley force-pushed the adopt-GHA-Scala-Library-Release-Workflow branch 5 times, most recently from 46a290c to 20570f1 Compare January 24, 2024 17:54
This is just prior to the main work of #232
@rtyley rtyley force-pushed the adopt-GHA-Scala-Library-Release-Workflow branch from 20570f1 to b48291c Compare January 24, 2024 18:08
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.
@rtyley rtyley force-pushed the adopt-GHA-Scala-Library-Release-Workflow branch from b48291c to d037761 Compare January 24, 2024 18:15
@guardian guardian deleted a comment from github-actions bot Jan 24, 2024
@rtyley rtyley marked this pull request as ready for review January 24, 2024 18:18
@rtyley rtyley requested a review from a team as a code owner January 24, 2024 18:18
@emdash-ie
Copy link
Contributor

Looks good! Nice to have the workflow handling npm and maven together :)

@Divs-B
Copy link
Contributor

Divs-B commented Jan 25, 2024

Thankyou @rtyley for adding NPM release too in gha-scala-library-release-workflow, "Preview" release looks great! https://www.npmjs.com/package/@guardian/content-api-models?activeTab=versions

Details in PR description are great to understand. 👍

@rtyley rtyley merged commit 553a91d into main Jan 25, 2024
1 check passed
@rtyley
Copy link
Member Author

rtyley commented Jan 25, 2024

Thanks both! After merging, I ran a standard full release on the default main branch, and it completed successfully with v18.0.1:

image

@rtyley rtyley deleted the adopt-GHA-Scala-Library-Release-Workflow branch January 25, 2024 11:25
rtyley added a commit to guardian/content-api-scala-client that referenced this pull request Jan 25, 2024
…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 .
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants