Releasing track
This page covers the current release workflow for track.
Configuration
Section titled “Configuration”release-please is configured in config.json and manifest.json.
The release version tracked by release-please lives in Cargo.toml. The workspace version and the internal track-* workspace dependency versions are marked with # x-release-please-version.
Workflows
Section titled “Workflows”The repository currently uses these release workflows:
- release.yml
Runs on pushes to
mainand on manual dispatch. It only handles therelease-pleaseflow, and whenrelease-pleasecreates a new release, this workflow calls the shared post-release workflow. - post-release.yml
Verifies the GitHub release exists, sets its title to
track vX.Y.Z, publishes the multi-architecture Docker image to GHCR, and uploads the shared release asset bundle. - recover-release-assets.yml
Manual recovery workflow for an existing release version. It rebuilds the shared release assets from the release tag and reruns the post-release publication steps. Its
publish_latestinput defaults tofalse.
Manual dispatches for the release and recovery workflows are restricted to main.
Published Artifacts
Section titled “Published Artifacts”Each release currently publishes:
- a GitHub release named
track vX.Y.Z trackup-assets-vX.Y.Z.tar.gztrack-vX.Y.Z-sha256sums.txtghcr.io/popzxc/track:vX.Y.Zas a multi-architecture manifest forlinux/amd64andlinux/arm64ghcr.io/popzxc/track:latestas a multi-architecture manifest forlinux/amd64andlinux/arm64
trackup installs track from the tagged source release with cargo install.
The backend wrapper keeps using those single GHCR tags, and Docker resolves the
right Linux image for the host automatically. On Linux x86_64, trackup
prompts for the default or CUDA-accelerated CLI build.