Integrate with changesets tool #1414
Conversation
jonsnyder
left a comment
jonsnyder
left a comment
There was a problem hiding this comment.
I'm so happy you did this. Our old system has been broken for some time. Will this publish a "Release" within GitHub with release notes?
I'd love to have this release process in the extension too, or we could include the extension as a package in this repo. It is a little different though because we don't publish the extension to NPM, but to Tags. What would you recommend?
| pnpm install --frozen-lockfile | ||
| pnpm exec changeset status --output=changeset-status.json | ||
| HAS_RELEASES=$(node -e "const s=require('./changeset-status.json');console.log((s.releases || []).length > 0 ? 'true' : 'false');") | ||
| echo "has_releases=${HAS_RELEASES}" >> "${GITHUB_OUTPUT}" |
There was a problem hiding this comment.
I'm a little worried we will get some un-expected version numbers and have them published to NPM. Can you add a call here to "ppm exec changeset status --verbose" so that we can manually review what it is going to do? Also make both publishes require manual approval at least until we are confident in how it operates.
|
|
||
| - name: Re-enter beta prerelease for next cycle after a stable release | ||
| if: hashFiles('.changeset/pre.json') == '' | ||
| run: pnpm changeset pre enter beta |
There was a problem hiding this comment.
I'd prefer to have an alpha -> beta -> stable release process.
In general these would be the rules:
alpha: We can merge in any approved PR
beta: We are trying to test things so only allow merges for fixes found during tested (no new things)
stable: We are done with testing so let's release the final versions then immediately go to alpha.
To move from alpha->beta we could manually run "ppm changeset pre enter beta" and submit a PR. Or we could define a workflow that can be manually run that would do the same. Could we add a merge rule to not allow merges if the PR contains a changeset and we are in beta?
Warning
This PR is based off of #1412 and should be merged after itDescription
"Changesets" is "A tool to manage versioning and changelogs
with a focus on multi-package repositories".
The idea is that, when you are making changes to the repo that are public-facing, you will
pnpm changesetThe markdown file looks like this:
with this information, the ChangeSets tool will automate moving the version number. It can also handle alpha and beta releases by the pre-release mode.
Together with this change is a new release automation process. So this PR will set us into beta mode. And then there is a GitHub workflow that will, when there are changes that are public-facing and main is merged, it will automatically bump the version number and then release to NPM. When it is time to release the stable version, we will manually disable the pre‑release mode and then commit that to main where the change set tool and the new automation will automatically release that new stable version and then put us back into alpha pre‑release mode.
This replaces a lot of the custom scripts that we had. The bulk of the work went into the release. Focus/start your review efforts there.
Related Issue
Motivation and Context
Screenshots (if appropriate):
Checklist: