lab download paths hard-code release tag "latest" but CI publishes latest-<branch> #321

New issue

Open

opened 2026-06-10 14:27:57 +00:00 by sameh-farouk · 0 comments

sameh-farouk commented

2026-06-10 14:27:57 +00:00

Member

Summary

lab's Forge download paths hard-code the release tag "latest", but the
canonical release CI (lab-release.yaml, on main of the hero_* repos)
publishes per-branch tags: latest-main, latest-development,
latest-integration. As a result, lab service <repo> --download and
lab build --download query a release tag that those repos never produce, so
prefetch fails to find any platform assets.

Where the tag is hard-coded

All three sites in crates/lab/src/service/acquire.rs (on main):

acquire.rs:285 — forge_prefetch_repo() → download_release_assets_for_labels(..., "latest", ...)
acquire.rs:385 — fetch_remote_asset_text(..., "latest", ...) (the .md5 cache probe)
acquire.rs:433 — download_release_assets(..., "latest", ...) (the lab build --download path)

These resolve to GET /api/v1/repos/{owner}/{repo}/releases/tags/latest
(crates/lab/src/repo/releases.rs:270), i.e. a tag literally named latest.

What the release CI actually publishes

.forgejo/workflows/lab-release.yaml (canonical, present on main of e.g.
hero_planner) sets:

TAG: latest-${{ github.ref_name }}
# main -> latest-main (prerelease=false), development -> latest-development, integration -> latest-integration (prerelease=true)

So a push to main creates/updates latest-main, never latest.

Impact

lab service <repo> --download / lab build --download against any repo
using lab-release.yaml dies with "no platform assets found" — the tag
latest does not exist.
Note lab install lab (scripts/lab_install.sh) is unaffected: it queries
the /releases/latest endpoint (latest non-prerelease, by asset name), not
a tag named latest, so latest-main (prerelease=false) is returned
correctly. The bug is specific to the tag-name lookups above.

Suggested fix

Make the download tag branch-aware instead of a constant. Options:

Resolve the tag as latest-<channel> where <channel> defaults to main
and is overridable (e.g. --channel flag / HERO_RELEASE_CHANNEL env),
mirroring how the CI derives latest-${ref_name}.
Or fall back: try latest, then latest-main, then the /releases/latest
endpoint.

Option 1 is preferred — it matches the publish convention exactly and is
explicit about which channel a download pulls from.

Notes

Found while tracing whether a push to main produces a release consumable by
lab download subcommands. The hero_skills own lab-publish.yaml still uses
the bare latest tag, so its own binaries happen to match; the mismatch
surfaces for repos migrated to lab-release.yaml's latest-<branch> scheme.

## Summary `lab`'s Forge download paths hard-code the release tag `"latest"`, but the canonical release CI (`lab-release.yaml`, on `main` of the hero_* repos) publishes per-branch tags: `latest-main`, `latest-development`, `latest-integration`. As a result, `lab service <repo> --download` and `lab build --download` query a release tag that those repos never produce, so prefetch fails to find any platform assets. ## Where the tag is hard-coded All three sites in `crates/lab/src/service/acquire.rs` (on `main`): - `acquire.rs:285` — `forge_prefetch_repo()` → `download_release_assets_for_labels(..., "latest", ...)` - `acquire.rs:385` — `fetch_remote_asset_text(..., "latest", ...)` (the `.md5` cache probe) - `acquire.rs:433` — `download_release_assets(..., "latest", ...)` (the `lab build --download` path) These resolve to `GET /api/v1/repos/{owner}/{repo}/releases/tags/latest` (`crates/lab/src/repo/releases.rs:270`), i.e. a tag literally named `latest`. ## What the release CI actually publishes `.forgejo/workflows/lab-release.yaml` (canonical, present on `main` of e.g. `hero_planner`) sets: ``` TAG: latest-${{ github.ref_name }} # main -> latest-main (prerelease=false), development -> latest-development, integration -> latest-integration (prerelease=true) ``` So a push to `main` creates/updates `latest-main`, never `latest`. ## Impact - `lab service <repo> --download` / `lab build --download` against any repo using `lab-release.yaml` dies with "no platform assets found" — the tag `latest` does not exist. - Note `lab install lab` (`scripts/lab_install.sh`) is unaffected: it queries the `/releases/latest` *endpoint* (latest non-prerelease, by asset name), not a tag named `latest`, so `latest-main` (prerelease=false) is returned correctly. The bug is specific to the tag-name lookups above. ## Suggested fix Make the download tag branch-aware instead of a constant. Options: 1. Resolve the tag as `latest-<channel>` where `<channel>` defaults to `main` and is overridable (e.g. `--channel` flag / `HERO_RELEASE_CHANNEL` env), mirroring how the CI derives `latest-${ref_name}`. 2. Or fall back: try `latest`, then `latest-main`, then the `/releases/latest` endpoint. Option 1 is preferred — it matches the publish convention exactly and is explicit about which channel a download pulls from. ## Notes - Found while tracing whether a push to `main` produces a release consumable by `lab` download subcommands. The hero_skills own `lab-publish.yaml` still uses the bare `latest` tag, so its own binaries happen to match; the mismatch surfaces for repos migrated to `lab-release.yaml`'s `latest-<branch>` scheme.