This repo uses Changesets for version orchestration and three publish paths:
the CLI (executor npm package plus its platform packages), the
@executor-js/* library packages (core, sdk, and the public plugins), and
the self-host Docker image.
- Add a changeset in the PR that should ship:
bun run changeset
- Merge that PR to
main. .github/workflows/release.ymlopens or updates aVersion PackagesPR.- Merge the
Version PackagesPR. - The release workflow then does two things in parallel:
- Publishes every
@executor-js/*library package whose current version is not already on npm, viabun run release:publish:packages(seescripts/publish-packages.ts). - If
apps/cli/package.jsonbumped, tags the commit and dispatches.github/workflows/publish-executor-package.yml, which:- runs
bun run release:check - performs a full dry-run release build before publish
- publishes the CLI npm package under the correct dist-tag
- creates or updates the GitHub release with build artifacts
- dispatches
.github/workflows/publish-desktop.yml - dispatches
.github/workflows/publish-selfhost-docker.yml
- runs
- Publishes every
- The self-host Docker workflow publishes
ghcr.io/rhyssullivan/executor-selfhostforlinux/amd64andlinux/arm64:- stable releases get
vX.Y.Z,X.Y.Z, andlatest - prereleases get
vX.Y.Z-...,X.Y.Z-..., andbeta
- stable releases get
Enter prerelease mode before starting a beta train:
bun run release:beta:start
That commits .changeset/pre.json into the repo and causes future release PRs to produce versions like 1.5.0-beta.0, 1.5.0-beta.1, and so on.
When the beta train is done:
bun run release:beta:stop
Stable versions publish to npm under latest.
Beta versions publish to npm under beta.
To build the full CLI release payload without publishing to npm or GitHub:
bun run release:publish:dry-run
That produces:
- platform archives in
apps/cli/dist - the packed wrapper tarball in
apps/cli/dist/release
To pack the @executor-js/* library packages without publishing:
bun run release:publish:packages:dry-run
To validate the self-host Dockerfile locally without publishing:
docker build -f apps/host-selfhost/Dockerfile -t executor-selfhost:local .
Release notes follow the standard Changesets flow: the changeset body
IS the changelog entry. Write the user-facing summary in the
.changeset/*.md you add with your PR; changeset version compiles
every changeset into the bumped packages' CHANGELOG.md files (via
@changesets/changelog-github, which links the PR and credits the
author), and apps/cli/src/release.ts uses the released version's
section of apps/cli/CHANGELOG.md as the GitHub Release body. If the
section is missing it falls back to gh release create --generate-notes.
There is no separate release-notes file to remember to update — if your change deserves a mention, its changeset body is the mention.
Write changeset bodies for users, not for the diff:
- Lead with the user-visible behavior, not the implementation.
- A typical fix is one sentence. A feature can be a short paragraph.
- For a large release, a changeset body can be a full markdown section
(bold sub-headings + bullets). Avoid
#/##headings inside bodies — they end up nested inside a changelog list item. - For breaking changes, include the before/after surface in the body.
Contributor attribution is automatic: @changesets/changelog-github
prefixes each entry with the PR link and the author's handle.
- Changesets owns the published CLI version via
apps/cli/package.json. - Only the Version Packages PR should change
apps/cli/package.json; the rest of the workspace is not version-synced for release PRs. - Per-package
CHANGELOG.mdfiles are seeded for every workspace package (bun run lint:changelog-stubs --fix).changeset versioninserts generated sections after the H1, and thechangesets/action@v1GitHub Action reads each bumped package'sCHANGELOG.mdto build the Version Packages PR description (it crashes withENOENTif any are missing). @changesets/changelog-githubneeds aGITHUB_TOKENwhen runningchangeset version(it resolves PR numbers and authors). CI provides one; locally useGITHUB_TOKEN=$(gh auth token) bun run changeset:version.- The publish workflow supports either npm trusted publishing or an
NPM_TOKENsecret. - Re-running the publish workflow for the same tag is safe for packages that are already on npm; existing versions are skipped.