Switch to Changesets-based release process #118
Conversation
| on: | ||
| push: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
we should be able to rename the base branch now - we need to preserve master as artifact of the past though as all existing users are using that ref at the moment
| @@ -0,0 +1,35 @@ | |||
| const path = require("path"); | |||
There was a problem hiding this comment.
I've done my best to test this before creating the PR - but as with any CI work... i could miss something and we'll have to supervise the first automated run of this script
Andarist
force-pushed
the
use-changesets
branch
from
20c04cf
to
f4c3c74
Compare
scripts/release.js
Outdated
| @@ -0,0 +1,35 @@ | |||
| const path = require("path"); | |||
| const { exec, getExecOutput } = require("@actions/exec"); | |||
| const tag = `v${require("../package.json").version}`; | |||
There was a problem hiding this comment.
There is also a question - what version should we release first? I probably would say that we should immediately bump to v1 - leaving a possibility to add all missing tags retroactively in the future
| - name: Checkout Repo | ||
| uses: actions/checkout@master | ||
|
|
||
| - name: Setup Node.js 12.x |
There was a problem hiding this comment.
Shouldn't we use at least node 14?
There was a problem hiding this comment.
I'm not sure if that has changed since then but apparently noode 14 couldn't be used a few months back:
actions/github-script#182 (comment)
There was a problem hiding this comment.
Where is actions/github-script being used?
There was a problem hiding this comment.
ah, i might have confused both things in a hurry - it might only not be possible to use node 14 for action itself but a workflow through setup-node action can actually use node 14
|
|
||
| - name: Install Dependencies | ||
| run: yarn | ||
|
|
There was a problem hiding this comment.
Add a step to build the code here?
There was a problem hiding this comment.
build is happening within the release script - and it's only done after we check if we need to release at all, so this is a minor optimization of the execution run, since most of the runs wont need to release and thus wont have to run build
| version: yarn version | ||
| publish: yarn release |
There was a problem hiding this comment.
Can you explain why do we need those two custom built scripts? 🤔
There was a problem hiding this comment.
version:
- runs changeset version
- and updates README
release:
- checks if the current version has already been released
- builds
- commits
- tags the commit
- pushes the tag out
It's not a standard npm-based flow that is somewhat assumed by Changesets.
|
Could we add a |
Co-authored-by: Nicola Molinari <[email protected]>
|
@mitchellhamilton Ok, makes sense - I've implemented the suggested change |
| await exec("git", [ | ||
| "push", | ||
| "--force", | ||
| "--follow-tags", | ||
| "origin", | ||
| `HEAD:refs/heads/${releaseLine}`, | ||
| ]); |
There was a problem hiding this comment.
note that i've chosen to use a branch for this because branches sync better than tags between remote and a local copy, to push out a tag with the same label we need to first destroy it and recreate. In general, I prefer to treat tags as immutable pointers.
|
The code looks fine to me, I'm thinking we should merge this to a new |
|
@mitchellhamilton do u want to do it or should i go with it when i wake up? |
|
Happy for you to do it |
The goal of this PR is to have a good release process in place. After this lands we should:
distwont be committed now)distbefore merging and a bad actor could tamper with this)