ci: migrate semantic-release to changesets

[JounQin]

What: close #441

Why: Using semantic-release is really a bad experience to me these days...

How: implemented

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9e70124

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[kylemh]

For the uninitiated, will you add more to the changesets readme on how we should go about releasing?

[JounQin]

For the uninitiated, will you add more to the changesets readme on how we should go about releasing?

Sure, thanks for reminding!

---

@kylemh Done!

[codecov-commenter]

Codecov Report

Merging #443 (1ec296a) into master (3eef076) will not change coverage.
The diff coverage is n/a.

❗ Current head 1ec296a differs from pull request most recent head b80e046. Consider uploading reports for the commit b80e046 to get more accurate results

@@            Coverage Diff            @@
##            master      #443   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            4         4           
  Lines          165       165           
  Branches        27        27           
=========================================
  Hits           165       165           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[kachkaev]

There is an issue with using secrets.GITHUB_TOKEN and Changesets: changesets/action#187 (comment)

Might be worth replacing with secrets.CUSTOM_GITHUB_TOKEN in a follow-up PR.

[JounQin]

There is an issue with using secrets.GITHUB_TOKEN and Changesets: changesets/action#187 (comment)

Might be worth replacing with secrets.CUSTOM_GITHUB_TOKEN in a follow-up PR.

Thanks for pointing it out, but I didn't meat this issue previously. Of it occurrs, we can try to align.

[JounQin]

There is an issue with using secrets.GITHUB_TOKEN and Changesets: changesets/action#187 (comment)

Might be worth replacing with secrets.CUSTOM_GITHUB_TOKEN in a follow-up PR.

@kachkaev

Now, I think the GitHub's default behavior is a very good feature, a PR generated by changesets do not need to run CI tasks IMO, they just remove changesets files, change CHANGELOG.md and update package.json, there seems nothing to check on CI, HDYT?

[kachkaev]

I see what you mean. Not running GitHub Actions for ‘Version packages’ PR will save some compute time indeed. There is pretty much zero chance for those checks to fail, so not running them may make sense.

The situation changes if at least one PR check is required:

This will block the merge button.

This repo does not seem to have any required PR checks, so using CUSTOM_GITHUB_TOKEN does not seem necessary, at least for now.

[JounQin]

The situation changes if at least one PR check is required

I met this situation previously indeed, and it's a @github's production issue IMO.