Repository navigation
Support for canary releases based on changesets? #855
Description
Hi there!
We at The Guild are working with changesets extensively. One of the solution we implement on top of the current implementation of changesets is the ability to easily connect canary/alpha releases, based on active changesets.
To do that, we are applying a minimal patch file to changesets code, in order to allow flexibility in the release flow.
I'm sharing an overview of the technical changes we are doing today, and I can also create a PR if this makes sense. I was thinking of a workflow of changesets version canary in the CLI.
The canary / alpha workflows
- To release a canary based on changesets, we are scanning and reading all relevant changesets that are currently available in the repo.
- Then, we run
assembleReleasePlanand builds the complete plan as changesets plan to release it (on the next release planned) - Then, we modify the version to be
{plannedVersion}-canary.{COMMIT_ID} - Run
applyReleasePlanto apply the change temporarily - Run changesets publishing script with
--tag canary
Here's the script we are using: https://github.com/B2o5T/graphql-eslint/blob/master/scripts/canary-release.ts
This way - changesets are used as the source of truth to the packages that actually was changed and needs to be released - and we apply an empheral change to the versioning before publishing it to npm.
Allowing non-ranged publishing
As part of the canary release workflows, we want to make sure to get rid of all possible ranges (^ / ~) in the internal packages dependencies, to make sure to get the exact versions of the canary changes.
To do that, we added a new argument to versionPackage function, called ignoreRange
Activity
emmatown commentedon Jun 29, 2022
This sounds like snapshot releases (or at least the intent behind them).
Using
plannedVersioninstead of0.0.0can be done with___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.useCalculatedVersionForSnapshotsthough you can't currently use a commit.@Andarist I'm kinda thinking we should have a "snapshot version template" config option,
So you could make have some variables that we provide like:
tagcommittimestampplannedVersion(v not sure about this name)and the default would be
0.0.0-{tag}-{timestamp}to align with the current behavior and you could express whatever and it would replace___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.useCalculatedVersionForSnapshotsand #830.Snapshot releases should definitely use exact versions for dependencies (I'm surprised that's not already true tbh). Do you want to create a PR for that?
dotansimha commentedon Jun 29, 2022
Oh, wow, I totally missed the
snapshotrelease option.I tested it now, and here are my thoughts:
canary/alphareleases.useCalculatedVersionForSnapshotsseems to work great, I guess it's under experimental due to the template idea? (which I really prefer better over a boolean, this should make snapshot releases simpler to manage and customize).CHANGELOGfile is created during theversionexecution - do you think it's valuable to allow to pass--no-changelogtoversioncommand in order to avoid it? (due to the temporary nature of these releases, I don't think we need a CHANGELOG record?)versioncommand:I can open the following PRs:
useCalculatedVersionForSnapshotsand support forsnapshotVersionTemplate: stringwith the placeholders you mentioned.--no-changelog?Does it make sense?
Thanks @mitchellhamilton
dotansimha commentedon Jun 29, 2022
@mitchellhamilton I created a PR to fix the exact versioning when snapshot release is performed: #857
dotansimha commentedon Jun 29, 2022
@mitchellhamilton Created another PR for adding
snapshotVersionTemplateand drop theuseCalculatedVersionForSnapshotsflag: #858Andarist commentedon Jun 29, 2022
Are there any downsides to updating CHANGELOGs there? You are not supposed to commit the output of a snapshot release anyway.
dotansimha commentedon Jun 30, 2022
Yeah, not committing it, just noticed it's generated anyway (while testing locally). I guess it's very minor :)
Andarist commentedon Jun 30, 2022
It might actually be somewhat nice to have those generated because you might always easily check in the package itself what kind of a change has been published in a given snapshot release.