This guide documents the current Amber CLI release path and the checks we expect before updating any public install instructions.
A successful release means all of the following happen without manual file editing:
- A published GitHub release in
amberframework/amber_clibuilds macOS and Linux binaries. - The workflow uploads release archives and checksum files to that release.
- The workflow dispatches
amberframework/homebrew-amber_cli. - The tap rewrites
Formula/amber_cli.rbwith the new version and checksums. - The tap's smoke test proves a clean machine can:
brew tap amberframework/amber_clibrew install amber_clibrew test amber_cliamber new smoke_app -y --no-deps
If any one of those steps is red, the release is not ready to announce.
Every PR that changes installation, packaging, generated scaffolds, or release automation should document:
- why the change is needed now
- whether it affects the release or install path
- what verification proves it works
- which ADR or SOP entry explains the longer-lived decision
Use the repository PR template for this so release context stays attached to the code review itself.
amberframework/amber_cliamberframework/homebrew-amber_cliFormula/amber_cli.rb.github/workflows/update-formula.yml.github/workflows/validate-install.yml
amberframework/amber_cli needs a HOMEBREW_TAP_TOKEN secret that can dispatch workflows in amberframework/homebrew-amber_cli.
Recommended scopes for a classic PAT:
repoworkflow
Update shard.yml to the release version you want to publish.
From the CLI repo:
./scripts/build_release.sh 2.0.1That should produce:
dist/amber_cli-darwin-arm64.tar.gzordist/amber_cli-linux-x86_64.tar.gz- matching
.sha256output
Before publishing a release, test the exact workflow on the branch you plan to tag:
gh workflow run release.yml \
--repo amberframework/amber_cli \
--ref <branch> \
-f ref=<branch>This exercises the same build matrix as the release workflow without uploading assets or touching the tap.
After the dry-run is green:
git tag v2.0.1
git push origin v2.0.1
gh release create v2.0.1 --repo amberframework/amber_cli --generate-notesPublishing the release triggers the automated flow:
- build macOS and Linux binaries
- upload archives and checksums to the release
- dispatch the Homebrew tap update
- run the tap smoke test on macOS and Linux
In amberframework/amber_cli, the release workflow must be green for:
Build darwin-arm64Build linux-x86_64Upload Release AssetsNotify Homebrew Tap
In amberframework/homebrew-amber_cli, the formula update workflow must be green for:
Update Formula
In amberframework/homebrew-amber_cli, the install smoke workflow must be green for:
Install Smoke Test (macos-latest)Install Smoke Test (ubuntu-latest)
That workflow explicitly runs:
brew tap amberframework/amber_cli
brew install amber_cli
brew test amber_cli
amber new smoke_app -y --no-depsand then verifies the scaffolded app can resolve shards and compile.
If the tap update fails after a release:
- Download the release assets and checksum files from GitHub.
- Update
Formula/amber_cli.rbinamberframework/homebrew-amber_cli. - Commit and push to
main. - Re-run
.github/workflows/validate-install.yml.
If the release build fails before the tap update:
- fix the workflow on a branch
- re-run the dry-run build with
workflow_dispatch - cut a new tag or recreate the release once the build is green
The Homebrew tap is our supported install path today.
For eventual homebrew/core inclusion, we should plan for a source-building formula and a clean brew audit --new --formula amber_cli story. The current tap keeps release onboarding fast, while the source-build path is the more likely route for upstream Homebrew acceptance.