You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The demo container from #223 must be built locally today: clone the repository, then docker build an image of about 3 GB before anything runs.
Publishing a pre-built, version-tagged image removes both steps, so trying TraceML becomes a single docker run with no checkout.
Proposed approach
Add a GitHub Actions workflow (for example .github/workflows/docker-publish.yml) that builds the existing root Dockerfile and pushes the image on every version tag.
Publish to GHCR as ghcr.io/traceopt-ai/traceml-demo, since pushing there needs only the built-in GITHUB_TOKEN and no extra registry account. Docker Hub is a fine alternative if broader discoverability matters more; the workflow shape is the same with docker/build-push-action.
Tag with the release version plus latest (for example traceml-demo:0.3.5 and traceml-demo:latest).
Build for linux/amd64 at minimum; add linux/arm64 via buildx if the runner budget allows, since Apple Silicon hosts are common for evaluation.
Update the README "Try it in Docker" section so the primary path is docker run --rm ghcr.io/traceopt-ai/traceml-demo, with the local docker build kept as the from-source alternative.
Why
This is the established pattern for comparable projects: PyTorch, Ray, and vLLM all publish version-tagged images built by CI, and their quickstarts lead with docker run against the published image.
A registry image also makes the demo usable in places a local build is impractical, such as a quick check on a remote box.
Out of scope
GPU-enabled image variants (separate issue).
Multi-container or compose setups (separate issue).
Nightly or per-commit image builds; releases only.
Acceptance
After a release tag, the workflow pushes a version-tagged image without manual steps.
On a clean machine with no repository checkout, docker run --rm ghcr.io/traceopt-ai/traceml-demo (or the chosen registry path) exits 0 and prints the input-bound diagnosis, same as the local build from Add a CPU-first TraceML demo container #223.
The README documents the published-image path as the primary quickstart command.
Target branch
Please base this on version_0.3.5 so the later merge into main stays clean.
Builds on the Dockerfile shipped in #223.
Summary
The demo container from #223 must be built locally today: clone the repository, then
docker buildan image of about 3 GB before anything runs.Publishing a pre-built, version-tagged image removes both steps, so trying TraceML becomes a single
docker runwith no checkout.Proposed approach
.github/workflows/docker-publish.yml) that builds the existing rootDockerfileand pushes the image on every version tag.ghcr.io/traceopt-ai/traceml-demo, since pushing there needs only the built-inGITHUB_TOKENand no extra registry account. Docker Hub is a fine alternative if broader discoverability matters more; the workflow shape is the same withdocker/build-push-action.latest(for exampletraceml-demo:0.3.5andtraceml-demo:latest).linux/amd64at minimum; addlinux/arm64via buildx if the runner budget allows, since Apple Silicon hosts are common for evaluation.docker run --rm ghcr.io/traceopt-ai/traceml-demo, with the localdocker buildkept as the from-source alternative.Why
This is the established pattern for comparable projects: PyTorch, Ray, and vLLM all publish version-tagged images built by CI, and their quickstarts lead with
docker runagainst the published image.A registry image also makes the demo usable in places a local build is impractical, such as a quick check on a remote box.
Out of scope
Acceptance
docker run --rm ghcr.io/traceopt-ai/traceml-demo(or the chosen registry path) exits 0 and prints the input-bound diagnosis, same as the local build from Add a CPU-first TraceML demo container #223.Target branch
Please base this on
version_0.3.5so the later merge intomainstays clean.Builds on the Dockerfile shipped in #223.
Part of #241.