-
Notifications
You must be signed in to change notification settings - Fork 337
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
Automate publish to npm #5637
Automate publish to npm #5637
Conversation
📋 StatsFile sizes
Modules
View stats and visualisations on the review app Action run for 16674c1 |
a32176b
to
a10bb9e
Compare
6f3c827
to
8765317
Compare
b30fc24
to
690e1a5
Compare
690e1a5
to
5a24734
Compare
5a24734
to
a9f3f8d
Compare
a9f3f8d
to
cb34ea0
Compare
cb34ea0
to
6197664
Compare
6197664
to
a22a7a8
Compare
1d5813c
to
224b8f7
Compare
224b8f7
to
4b7719f
Compare
For pre-releases, we ignore the output of the generate-npm-tag script, so we no longer need to include it in the old process. Update publish-release.sh to become publish-prerelease.sh so that the legacy workflow still works for pre-releases until we swap them over.
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.
Left one clarifying question and one future comment. Generally happy with this. I've checked this against our other dispatchable workflows that I can't run them when I'm not logged in which is a good sign for security, but it'd be good to confirm that only DS team members/devs can run them, or at least alphagov org members.
|
||
if [ $CURRENT_VERSION == $HIGHEST_PUBLISHED_VERSION ]; then | ||
echo "⚠️ Git tag $TAG already exists. Check you have run `npm version` correctly." | ||
if [ "$CURRENT_VERSION" = "$HIGHEST_PUBLISHED_VERSION" ]; then |
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.
Should that be a double equals? I'm worried I'm missing something as I'd expect this to be a declaration instead of a comparisson, but maybe this is doing something else?
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.
I'm not an expert on shell/bash, but essentially the double equals version is Bash-specific, whereas the single equals is "POSIX compliant", meaning it'll work in any generic shell script.
The fact that this script was running before means our GitHub runner has Bash on the go anyway, but thought I'd generify while I was in there.
I've made similar "POSIX-friendly" tweaks/choices on line 15 (using grep
) and line 20 (using cut
).
docs/releasing/publishing.md
Outdated
|
||
If you're following these instructions, you're probably doing a sequential release, meaning | ||
the tag should be 'latest'. | ||
2. Select the "RELEASE: Publish to npm" workflow and run the workflow on the `main` branch. This will publish the release to npm. |
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.
Not for right now but it'd be good to link directly to the workflow once we know where it lives in github's UI
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.
Good point! It should be at https://github.com/alphagov/govuk-frontend/actions/workflows/publish-to-npm.yaml unless we change the name of the yaml file, so I'll add that in.
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.
Done!
9da52a4
to
16674c1
Compare
What
resolves #5604
Adds a workflow for publishing to npm.
workflow_dispatch
The workflow must be manually dispatched. A release will be split into 3 workflows: building a release, publishing to npm and publishing to GitHub.
The end result of the build release stage is a PR which will require human review. Only once this PR has been approved and merge should the publish to npm step be run.
provenance
Provenance statements enable you to "publicly establish where a package was built and who published a package". This provides an extra layer of supply-chain assurance for folks who use our package. We now publish to npm with provenance.
generate-npm-tag
The
generate-npm-tag
shell script has been updated to add logic to deal withinternal
releases. It now works as follows:"internal"
, the npm tag will be set tointernal
latest
taglatest-[major-number]
tagWe've added this script as an npm script to enable direct access. It's also used within the
publish-release
script, which is currently used for pre-releases. However, our documentation has the user ignore the result of the script during pre-releases anyway, so this PR rejigs thepublish-release
script to no longer usegenerate-npm-tag
and renames the script topublish-prerelease
.It should be pretty easy to update the
generate-npm-tag
script with pre-release logic when we switch pre-releases over to GitHub Actions.