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

Automate publish to npm #5637

Merged
merged 5 commits into from
Jan 22, 2025
Merged

Automate publish to npm #5637

merged 5 commits into from
Jan 22, 2025

Conversation

domoscargin
Copy link
Contributor

@domoscargin domoscargin commented Jan 21, 2025

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 with internal releases. It now works as follows:

  • If we're trying to publish a version that already has a git tag, the script fails. The user will have to manually delete the git tag if they want to publish.
  • If the publish version contains the string "internal", the npm tag will be set to internal
  • If the version is higher than the latest published version, it gets the latest tag
  • If the version is lower than the latest published verison, it gets the latest-[major-number] tag

We'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 the publish-release script to no longer use generate-npm-tag and renames the script to publish-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.

Copy link

github-actions bot commented Jan 21, 2025

📋 Stats

File sizes

File Size
dist/govuk-frontend-development.min.css 118.52 KiB
dist/govuk-frontend-development.min.js 42.7 KiB
packages/govuk-frontend/dist/govuk/all.bundle.js 92.81 KiB
packages/govuk-frontend/dist/govuk/all.bundle.mjs 87.12 KiB
packages/govuk-frontend/dist/govuk/all.mjs 1.25 KiB
packages/govuk-frontend/dist/govuk/govuk-frontend-component.mjs 1.74 KiB
packages/govuk-frontend/dist/govuk/govuk-frontend.min.css 118.51 KiB
packages/govuk-frontend/dist/govuk/govuk-frontend.min.js 42.69 KiB
packages/govuk-frontend/dist/govuk/i18n.mjs 5.55 KiB
packages/govuk-frontend/dist/govuk/init.mjs 7.13 KiB

Modules

File Size (bundled) Size (minified)
all.mjs 82.57 KiB 40.4 KiB
accordion.mjs 26.58 KiB 13.41 KiB
button.mjs 9.09 KiB 3.78 KiB
character-count.mjs 25.39 KiB 10.9 KiB
checkboxes.mjs 7.81 KiB 3.42 KiB
error-summary.mjs 10.99 KiB 4.54 KiB
exit-this-page.mjs 20.2 KiB 10.34 KiB
header.mjs 6.46 KiB 3.22 KiB
notification-banner.mjs 9.35 KiB 3.7 KiB
password-input.mjs 18.24 KiB 8.33 KiB
radios.mjs 6.81 KiB 2.98 KiB
service-navigation.mjs 6.44 KiB 3.26 KiB
skip-link.mjs 6.4 KiB 2.76 KiB
tabs.mjs 12.04 KiB 6.67 KiB

View stats and visualisations on the review app


Action run for 16674c1

@domoscargin domoscargin marked this pull request as ready for review January 21, 2025 17:40
@domoscargin domoscargin requested a review from a team as a code owner January 21, 2025 17:40
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.
Copy link
Contributor

@owenatgov owenatgov left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

@domoscargin domoscargin Jan 22, 2025

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).


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.
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@govuk-design-system-ci govuk-design-system-ci temporarily deployed to govuk-frontend-pr-5637 January 22, 2025 11:20 Inactive
@domoscargin domoscargin merged commit 4d54892 into main Jan 22, 2025
48 checks passed
@domoscargin domoscargin deleted the automate-npm-publish branch January 22, 2025 11:44
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.

Automate npm publish
3 participants