Conversation
🦋 Changeset detectedLatest commit: c9b3f92 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
||
| jobs: | ||
| ensnode-build-and-push: | ||
| runs-on: blacksmith-4vcpu-ubuntu-2204 |
There was a problem hiding this comment.
I wonder if this CI Worker will have enough disk space to deal with the images to be built for ENSRainbow?
I guess one way of figuring it out is to go live with this PR and see.
package.json
Outdated
| "typecheck": "pnpm -r --parallel typecheck", | ||
| "changeset": "changeset", | ||
| "release": "changeset publish --filter='!@ensnode/shared-configs'", | ||
| "publish": "changeset publish", |
There was a problem hiding this comment.
changeset publish creates one release per package:
tk-o
left a comment
tk-o
left a comment
There was a problem hiding this comment.
If we need a single github release including information about multiple packages release notes, we cannot use Changesets to handle that for us. Changesets create a release per tag, and since each released package gets its own tag, we end up having multiple releases created by Changesets at the same time (effectively, one per package).
To end up with a single Github Release including all packages that were updated, we'll need to opt-out from the flow where Changesets manage Github Releases. We will need a replacement automation that will track if Changesets'-created Pull Request got merged, and if so, read the pull request contents and create a single Github Release.
For example, this Changesets-generated PR include information about three newly created package tags. We can simply copy this PR contents below Releases heading and put in to a new Github Release. All app packages are versioned with the same version number, so we could extract that number and included in to the Github Release title.
Thoughts on that approach?
| uses: actions/checkout@v4 | ||
| - name: Docker meta | ||
| id: meta | ||
| uses: docker/metadata-action@v5 |
| name: "Build: ENSNode Images" | ||
| on: | ||
| workflow_dispatch: | ||
| release: |
There was a problem hiding this comment.
I'm worried that we will be swarmed with both packages and app releases here. All of them will trigger this, and we will be building [sub_repos_count * 3] images at once.
| on: | ||
| workflow_dispatch: | ||
| release: | ||
| types: [published] |
There was a problem hiding this comment.
Also not sure if metadata step is working well with release trigger
3 participants
closes #546
gh release create— we might want to move to that approach