Sambee Companion releases are built and published once. A successful build automatically promotes the release to test; later channel promotion rewrites public feed files without rebuilding binaries.
Key differences between the Companion and Docker release paths:
- Docker releases promote an already published container image.
- Companion releases promote an already published GitHub Release by rewriting feeds read by Companion’s auto-updater and by the Sambee frontend.
- Docker images are available for Linux only, whereas Companion is a native app for Windows, Linux, and macOS. Each platform binary needs to be built on the respective OS.
Summary
If you want to take a new Companion version to stable, follow this order:
- Increment
VERSIONto the nextX.Y.Zvalue and run./scripts/sync-version. - Run
Release: Build Companion Artifact:- Select target platforms
- If the workflow’s source version field is left blank, the artifact is built from the current commit in
main, and the Git tagbuild-vX.Y.Zis created to reserve the version for the commit the artifact is built from. - If a source version field is specified, the workflow verifies and repairs the artifact associated with the version via the Git tag used for reservation.
- The workflow builds and signs Companion, publishes the verified immutable release in the
Companion GitHub repo
, promotes it to
test, and cleans up obsolete releases. - Test the published release through the
testchannel or by installing its release assets. - Run
Release: Promote Companion Releasewhen the release is approved forbeta,stable, or Sambee download metadata.
One published release can move from test to beta to stable without rebuilding binaries.
Read the detailed pages in this order:
- Build Companion Release
- Promote Companion Release
- Companion Channels, Feeds, And Downloads
- Companion Release Cleanup
Workflow Map
| Workflow | When to use it | Result |
|---|---|---|
Local npm run check:rust:windows | You want an early local Windows-target compatibility signal while working in Linux or the devcontainer. | Runs a Windows GNU target cargo check only. It does not create signed release assets. |
Release: Build Companion Artifact | You want to create release assets for one canonical version. | Builds the selected platform set, publishes the verified immutable GitHub Release, promotes only test, and cleans up obsolete releases. |
Release: Promote Companion Release | A published Companion release is approved for one or more channels or for Sambee download metadata. | Rewrites the selected feed files in docs/feeds of the release repository. |
Maintenance: Clean Up Companion Releases | You want to reconcile release retention outside a promotion run. | Validates the feed markers and deletes obsolete GitHub Releases. |
Main Control Points
| File or system | Role |
|---|---|
.github/workflows/build-companion.yml | Builds platform artifacts from a canonical source, publishes the verified release, promotes test, and runs cleanup. |
.github/workflows/promote-companion-release.yml | Promotes one published release to selected public feeds. |
.github/scripts/promote_companion_release.py | Resolves release assets and writes the feed JSON files. |
.github/scripts/cleanup_companion_releases.py | Validates feed references and applies Companion release retention. |
| helgeklein/sambee-companion | Dedicated public release repository for Companion GitHub Releases and committed feed source files. |
release-repo/docs/feeds | Source-controlled feed JSON files that promotion updates and commits ( docs ). |
Published Artifact
Published Companion releases live in helgeklein/sambee-companion as GitHub Releases.
Each release may contain:
- Installer assets.
- Tauri updater bundles.
.sigfiles for updater verification.- Release notes.