At the moment I'll use changesets manually to control versions.
But when an ML dev wants to release a new python service, I need the process to be as simple as merging to master.
I think we need to use the standard github action, which I think runs like this:
On merge to master, run pnpm changeset version to bump versions
Raise a PR with all the changes
When that PR is merged back in, trigger a release and push tags
That second PR to manage the release is kind of a drag. I suppose users could run bun changeset manually, and we build and tag on merge to main if there's no new changesets.
We need to think about how this works with the deploy policy. At the moment, when a version tag is pushed, we build the image and push to docker hub. I told Taylor I'd also do this for the next tag on any merge to master. I don't think we currently have auto-deploy setup.
In the new changesets world, we should only dockerize when the version tag has been pushed, and we should auto-deploy each tag to staging after dockerizing. We should also maintain a rolling next.
At the moment I'll use changesets manually to control versions.
But when an ML dev wants to release a new python service, I need the process to be as simple as merging to master.
I think we need to use the standard github action, which I think runs like this:
That second PR to manage the release is kind of a drag. I suppose users could run
bun changesetmanually, and we build and tag on merge to main if there's no new changesets.We need to think about how this works with the deploy policy. At the moment, when a version tag is pushed, we build the image and push to docker hub. I told Taylor I'd also do this for the
nexttag on any merge to master. I don't think we currently have auto-deploy setup.In the new changesets world, we should only dockerize when the version tag has been pushed, and we should auto-deploy each tag to staging after dockerizing. We should also maintain a rolling next.