[Other] No Docker images published since 0.2.3: ghcr.io latest-* frozen at 0.2.3, releases 0.2.3.1–0.2.6 have no images #4183

Area

Other

Desktop app, Terminal or source?

Docker

What happened

The container images on GitHub Container Registry stopped at 0.2.3 while releases kept shipping. docs/DOCKER.md states "Ready-made images are published from version 0.2.1 on, to the GitHub Container Registry … ghcr.io/niko1221/strata:latest-<flavor> for the newest release of that flavor", but there is no image for any release after 0.2.3, and the latest-<flavor> tags still point at the 0.2.3 image.

What I did / saw:

1. v0.2.6 was released 2026-10-25 with engine packages (strata-engine-0.1.50-*, strata-dsv41-0.1.51-*) as release assets.
2. ghcr.io/niko1221/strata tag list contains only 0.2.1-*, 0.2.2-*, 0.2.3-* and latest-* (22 tags). Nothing for v0.2.3.1, v0.2.4/.1/.2, v0.2.5, v0.2.6.
3. latest-cuda13 and 0.2.3-cuda13 resolve to the same manifest digest, so latest-* is not "the newest release of that flavor" anymore.
4. The Docker images workflow (.github/workflows/docker-images.yml) is workflow_dispatch-only by design ("Run by hand only … Nothing starts it on its own"). Its complete run history is 8 runs, all manual; the last ran 2026-10-23 09:25 UTC — the run that produced the 0.2.3 images. So no CI is broken: the manual publish step simply has not been run for any release since 0.2.3.

I searched open and closed issues (docker / ghcr / publish / image in title and body) and found no thread tracking this gap. What exists is adjacent, and it matters because it closes off the fallback:

• [Other] docker/build.sh leaves out tools/dsv41/*.py, so the image build stops at "installer tool missing: tools/dsv41/tune.py" #4082 — docker/build.sh leaves out tools/dsv41/*.py, so a from-source image build stops at "installer tool missing: tools/dsv41/tune.py" (reported there, not re-tested by me)
• [Other] docker image: stage the nested tools/ scripts the Terminal bundle reads (build stops at "installer tool missing: tools/dsv41/tune.py") #3974 — the same missing nested tools/ scripts from the image side (reported there, not re-tested by me)
• [Other] include dsv41 installer scripts in Docker build context #4140 — dsv41 installer scripts not in the Docker build context
• [Engine] add RX 6000 gfx1031 Docker image flavor #4139 — no gfx1031 image flavor

So today, users who need the engine fixes in 0.2.4–0.2.6 in Docker can neither pull an image nor reliably build one, while the docs keep presenting 0.2.3 examples as current.

Expected (per docs/DOCKER.md): a ready-made image for each version tag, and latest-<flavor> moved to the newest release of that flavor.
Actual: the newest published image is 0.2.3-cuda13 (and siblings) from 2026-10-23; releases v0.2.3.1 through v0.2.6 have no images and latest-* still points at 0.2.3.

What I'd like to see. The primary ask is small: dispatch Docker images for the current release (v0.2.6) with push on, and keep doing that per release. The workflow already supports everything needed (release_tag, flavors, push, latest, and a dry-run mode with push off).

Optional, maintainer's call, separate from the ask above: since the workflow comment says it is run by hand only, either note in the release checklist that the image dispatch is part of a release, or add an automatic dispatch (e.g. release: types: [published]) — but I understand not wanting to auto-publish, and the manual path is fine as long as it actually runs each release. If #4082 / #3974 / #4140 still break the image build for the dsv41 flavor, that would explain a skipped dispatch and those would gate the publish.

Smallest steps or command that reproduce it

Any of these, no credentials needed, any internet-connected machine:

# 1. The registry has nothing newer than 0.2.3 (anonymous pull; skopeo or crane both work)
skopeo list-tags docker://ghcr.io/niko1221/strata
# -> only 0.2.1-*, 0.2.2-*, 0.2.3-*, latest-* (22 tags)

# 2. latest-cuda13 is byte-identical to 0.2.3-cuda13
docker manifest inspect ghcr.io/niko1221/strata:latest-cuda13
docker manifest inspect ghcr.io/niko1221/strata:0.2.3-cuda13
# -> both return the same digest:
#    sha256:d39ca9fc583c5085dc66b857fbf3b3e3a9e256f692672d4061322d3bd468433a

# 3. The publish workflow has not run since 2026-10-23
curl -s "https://api.github.com/repos/Niko1221/Strata/actions/workflows/390274434/runs?per_page=20" \
  | jq '.workflow_runs[] | {run_number, event, created_at, status, conclusion}'
# -> 8 runs total, all workflow_dispatch, newest 2026-10-23T09:25:40Z success

Other environment details: registry checked ghcr.io/niko1221/strata (anonymous pull), 2026-10-26. Latest release v0.2.6 (published 2026-10-25T13:45:25Z), engine packages 0.1.50 / dsv41 0.1.51. Newest published images: 0.2.3-cuda13, 0.2.3-cuda12, 0.2.3-rocm-gfx110x, 0.2.3-rocm-gfx1151, 0.2.3-rocm-gfx120x, 0.2.3-sycl (sycl exists for 0.2.3 only; no 0.2.1/0.2.2 sycl tags). Workflow file: .github/workflows/docker-images.yml on main (workflow id 390274434).

Reproduction status

Reproduced locally — the registry tag list, the manifest digest equality (latest-cuda13 = 0.2.3-cuda13 = sha256:d39ca9fc583c…433a) and the Actions run history were verified directly on 2026-10-26 with the commands above. The #4082 / #3974 build-break is cited from those threads, not re-tested by me.

Strata version

Strata 0.2.6 · engine 0.1.50 · dsv41 0.1.51 (latest release, checked as release assets) vs. newest published ghcr.io image 0.2.3. The report is about what is published, not about a version I ran.

Graphics card, memory and system

Not hardware-specific: the check above runs on any internet-connected Linux/x86_64 machine (public registry and Actions APIs only). The affected deployment on our side is a Docker host with 4x RTX 3090 24 GB · 256 GB RAM · Linux, running a strata-deepseek container service that needs engine fixes from 0.2.4+.

Model, size and settings

Not applicable — this is about image publishing, observed across all flavors and models.