ci: automate the v-next release process using changesets#6565
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Copilot reviewed 5 out of 14 changed files in this pull request and generated no comments.
Files not reviewed (9)
- .changeset/config.json: Language not supported
- package.json: Language not supported
- pnpm-lock.yaml: Language not supported
- v-next/example-project/package.json: Language not supported
- v-next/hardhat-ethers-chai-matchers/package.json: Language not supported
- v-next/hardhat-ethers/package.json: Language not supported
- v-next/hardhat-ignition-ethers/package.json: Language not supported
- v-next/hardhat-typechain/package.json: Language not supported
- v-next/hardhat/templates/02-mocha-ethers/package.json: Language not supported
Comments suppressed due to low confidence (2)
v-next/hardhat/test/internal/cli/init/init.ts:283
- Refine the test skip conditions per the TODO comment to ensure only the intended release PR merge events bypass these tests, thereby avoiding unintended gaps in test coverage.
process.env.GITHUB_EVENT_NAME === "push" || // TODO: This check should be limited to push events associated with a release PR merge
v-next/hardhat-ethers/CHANGELOG.md:3
- Verify that the version number downgrade in the changelog from '4.0.0-next.2' to '3.0.0-next.2' is intentional and consistent with the overall release strategy.
## 3.0.0-next.2
| "@nomicfoundation/template-package", | ||
| "template-*" | ||
| ], | ||
| "fixed": [ |
There was a problem hiding this comment.
If we ever wanted to stop releasing all the packages together, we could group the ones linked through peer dependency relations here instead.
hardhatTotal size of the bundle: List of dependencies (sorted by size) |
| process.env.HARDHAT_DISABLE_SLOW_TESTS === "true" || | ||
| process.env.GITHUB_EVENT_NAME === "push" || // TODO: This check should be limited to push events associated with a release PR merge | ||
| process.env.GITHUB_EVENT_NAME === "merge_group" || // TODO: This check should be limited to merge_group events associated with a release PR merge | ||
| process.env.GITHUB_HEAD_REF?.startsWith("changeset-release/"), |
There was a problem hiding this comment.
This check is not ideal. As things stand, these tests would be executed in PRs only. I'll try to come up with a better heuristic.
| return changesets.length > 0; | ||
| } | ||
|
|
||
| async function validatePullRequest() { |
There was a problem hiding this comment.
This is a nit pick, don't change the PR. In this sort of case I would put the validatePullRequest function at the top, to ease reading from top to bottom - while keeping the invocation at the very bottom.
| if (line.startsWith('## ')) { | ||
| break | ||
| } | ||
| if (line === '### Patch Changes') { |
There was a problem hiding this comment.
This line we will need to be careful of when we shift to the full release process for 3.0.0. But the entire process will need reviewed for that.
I will add an issue to indicate we need to review and completely upgrade these scripts for 3.0.0:
kanej
left a comment
There was a problem hiding this comment.
This looks good. I left a few comments, and a suggested improvement to a comment (I would check that my understanding as expressed in the comment is correct).
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| GITHUB_TOKEN: ${{ github.token }} | ||
| uses: galargh/action-gh-release@571276229e7c9e6ea18f99bad24122a4c3ec813f # https://github.com/galargh/action-gh-release/pull/1 |
There was a problem hiding this comment.
Are we able to push this to Nomic to keep us self-contained?
There was a problem hiding this comment.
Looks like we should be able to use the https://github.com/softprops/action-gh-release version of the action instead of my fork now as both my PRs got merged there. I would leave it as a TODO for later though as I would like to carefully check what other things they introduced in their action.
There was a problem hiding this comment.
Ah. What is it that drives pulling in an external task here? Is the GitHub API around releases just really cumbersome here?
There was a problem hiding this comment.
Now that I think about it, we should be able to use the API directly in our case. This action is great for a little more advanced setups. Especially those where a draft gets updated over and over again. However, in our setup, we only ever create the draft once and that's it.
I'm going to update it to use the GitHub API directly. Thanks for pointing this out. I might not be able to finish it before our meeting though.
There was a problem hiding this comment.
Cool lets do that as a follow up PR.
I will mark this as approved.
Co-authored-by: John Kane <john@kanej.me>
This PR automates the release creation on the v-next branch. This includes publishing the packages to NPM registry and creating a GitHub release (in a draft mode).
TODO (before merge)
NODE_AUTH_TOKENin the repository secretsRead and write@nomicfoundation/*,hardhatRELEASE_GITHUB_TOKENin the repository secretspull-requests: read & write,contents: read & writeNomicFoundation/hardhatTesting
I performed manual testing in a forked repository. The testing did NOT include actually publishing the packages to npm. This is considered acceptable because in case the NPM publishing fails, we can always fall back to the manual release mode we've been following thus far.
Here are the testing scenarios I went through.
no changeset neededlabel. It was successfully validated in the PR and in the merge queue. After the merge, the release workflow did not publish the packages.