The Frodo CLI project uses an automated release pipeline defined in ../.github/workflows/pipeline.yml.
The workflow runs on:
- Pull requests to
main(build/test/packaging validation) - Pushes to
main(build/test validation only — no release) - Manual
workflow_dispatch(release — explicit release type selection)
All releases are manual. Release type is selected via workflow_dispatch input:
prerelease,patch,minor,major
Pushes to main run build and test validation but do not publish or create a release.
There is no PR-label-based release-type logic.
Build does the following:
- Uses deep checkout with tags (
fetch-depth: 0,fetch-tags: true) - Guards against version drift from latest npm/tagged release
- Resolves release type
- Computes next version with
vscheuber/version-bump-action@v1 - Guards against duplicate tag/version
- Updates manifests with
vscheuber/manifest-version-update-action@v1 - Builds CLI artifact and publishes build outputs for downstream jobs
Runs test matrix across Node versions, plus direct and proxy integration tests when secrets are available.
The pipeline builds, smoke-tests, and archives binaries for:
linux-x64linux-arm64macos-intelmacos-arm64windows-x64
npm-release runs after binary jobs and uses trusted publishing via vscheuber/npm-trusted-publish-action@v1.
For stable release types (patch, minor, major), it performs dual publish:
- Publishes companion prerelease
x.y.z-ntonext - Publishes stable
x.y.ztolatest
For prerelease, it publishes to next.
Release job:
- Downloads binary artifacts
- Generates changelog/release notes using
vscheuber/ai-changelog-action@v1 - Commits changelog and manifest updates
- Creates GitHub release with platform artifacts
Release assets include:
- ../CHANGELOG.md
- ../LICENSE
Release.txtfrodo-linux-x64-<version>.zipfrodo-linux-arm64-<version>.zipfrodo-macos-intel-<version>.zipfrodo-macos-arm64-<version>.zipfrodo-windows-x64-<version>.zip
After successful release + npm publish, the workflow updates Homebrew tap formulas (frodo-cli and frodo-cli-next).
Pipeline behavior in forks can differ due to missing secrets/permissions. Validate release behavior in the main repository before relying on fork runs for release-path testing.
If a bad release occurs:
-
Delete the incorrect GitHub release.
-
Revert release changes in ../CHANGELOG.md, ../package.json, and ../package-lock.json.
-
Merge the corrective PR.
-
Remove incorrect npm version if necessary:
npm unpublish @rockcarver/frodo-cli@<version> -
Remove incorrect tag if needed:
git push --delete origin v<version> -
Re-run release with the intended release type via
workflow_dispatch.
