Conversation
7865c9b to
b83f440
Compare
b83f440 to
5efaeb5
Compare
|
I think trying to keep the publishing processes between projects owned by the GOV.UK Design System team makes a ton of sense. To that end, is there any value in considering abstracting some of these scripts - my gut is probably not at this point but just a thought. On Finally if we adopt this, would we remove the existing scripts and guidance? |
|
@NickColley Good points. In order:
|
|
Something else I've noticed is that it looks like the release script tests just aren't running. It's unclear to me why. My best guess is because it's an mjs file but I don't understand why that would be stopping tests running. |
What it says. This copies Frontend's current strategy of managing releases as a multi-step process in CI rather than doing anything locally. This includes the github workflows themselves plus the helper scripts and their tests, which I've put in /scripts/github-actions
Finishing and validating this means we can delete the (broken) automated release scripts that the kit currently runs off of.
Like Frontend, this splits the process into 3 parts:
This is also missing CI secrets that allow us to run some of these.
Differences between the kit and Frontend
The kit tends to use simpler changelog titles ie: no 'v' before the version number and no release 'type' after the number eg: "v1.1.1 (fix release)". There's also not precident for the kit to do pre-releases like betas or rc's at the moment. Therefore I've simplified the helper scripts to not include interrogating differences between pre-releases and full releases or building complex titles.
The kit uses clean publish to handle publishing to npm rather than 'manual' publishing like Frontend does. It similarly don't appear to be as concerned with tagging. I've therefore simplified the publish to npm job to follow this release flow.