Douglas LowderandClaude Opus 5.5
8545feb433
* [ci] Version packages and generate changelogs with changesets PRs now add a changeset in .changeset/ instead of editing CHANGELOG.md. The manual release workflow runs scripts/src/versionPackages.ts, which runs `changeset version` for one fixed group of all packages, writes the root CHANGELOG.md section with the existing emoji categories, and then commits, tags, and pushes vX.Y.Z. The tag-driven publish is unchanged, except that it reads the changelog section from the tagged commit. The PR check validates changesets with @changesets/parse and rejects direct CHANGELOG.md edits. The "no changelog" label still skips it. Co-Authored-By: Claude Opus 5.5 <[email protected]> * Correct "no changelog" documentation in .changeset/README.md * [ci] Fail on CHANGELOG.md edits even with the "no changelog" label Co-Authored-By: Claude Opus 5.5 <[email protected]> * [ci] Skip the changeset check for Dependabot PRs Dependabot PRs only update dependencies, so they need no changeset, and their read-only token cannot post the PR comment. The job skips both for them. The CHANGELOG.md check still runs. The workflow now sets explicit token permissions. Co-Authored-By: Claude Opus 5.5 <[email protected]> * Remove the "## main" block from CHANGELOG.md Co-Authored-By: Claude Opus 5.5 <[email protected]> --------- Co-authored-by: Claude Opus 5.5 <[email protected]>
3.1 KiB
Releasing EAS CLI
- Invoke the GitHub workflow "Manually trigger a release". Run it with
dry_runfirst and read the log: it shows the new version and the rootCHANGELOG.mdsection. - Run it again with
dry_rununchecked. The workflow consumes the changesets in.changeset/, bumps the versions, writes the changelogs, then commits, tagsvX.Y.Z, and pushes tomain. - That's it! GitHub Actions is going to take care of the rest. Watch the #eas-cli Slack channel for a successful release notification.
The release also sets the STAGING and PRODUCTION versions in cli-versions.json. See EAS Build CLI versions.
EAS Build CLI versions
cli-versions.json at the repository root sets which eas-cli version EAS Build installs. It has two fields:
STAGING: the version used on the staging build servers.PRODUCTION: the version used on the production build servers.
This file replaces the old latest-eas-build and latest-eas-build-staging npm dist-tags. The build servers read the file from the main branch.
A release updates STAGING and PRODUCTION to the new version automatically. To set a different version to production (to fix a regression, for example), invoke the GitHub workflow "Promote eas-cli to production". Pass the version to promote as an input. If you leave the input empty, the workflow uses the current STAGING version. The workflow checks that the version is published on npm before it updates PRODUCTION.
Choosing the next version
The changesets in .changeset/ choose the next version. All packages share one version (a changesets fixed group), and the highest bump in all changesets wins:
- If any changeset has a
majorbump, bump the MAJOR version. - Otherwise, if any changeset has a
minorbump, bump the MINOR version. - Otherwise, bump the PATCH version.
A release fails if there are no changesets, or if all of them are none or empty. To force a bump, merge a changeset with that bump type. See .changeset/README.md for how to write a changeset.
What a release writes
yarn release (scripts/src/versionPackages.ts) does these steps:
- Reads the changesets and computes the new version.
- Runs
changeset version. This bumps everypackage.json, writes each package'sCHANGELOG.md, and deletes the changesets. - Sets the version in
lerna.json, updatesyarn.lock, and regeneratespackages/eas-cli/README.md. - Adds the new section to the root
CHANGELOG.md. The GitHub release and the Slack message use this section. - Commits
vX.Y.Z, tags it, and pushes. A dry run stops before this step.
The tag push starts the release workflow, which publishes to npm, publishes the GitHub release, and updates cli-versions.json.
The release looks up the PR and author of each changeset on GitHub, so a local dry run needs a GITHUB_TOKEN:
GITHUB_TOKEN=$(gh auth token) INPUT_DRY_RUN=true yarn release