lab build --upload: add --prerelease flag and anchor the release tag to the built commit #318

New issue

Closed

opened 2026-06-10 09:05:16 +00:00 by mahmoud · 0 comments

mahmoud commented

2026-06-10 09:05:16 +00:00

Owner

Summary

lab build --upload needs two small improvements so release publishing is correct and CI stays clean:

Add a --prerelease flag.
Anchor the release tag to the commit being built (the rolling tag must follow the branch tip).

Right now both are hardcoded in crates/lab/src/repo/releases.rs:

ensure_release() always sends "prerelease": false.
On create it always sends "target_commitish": "development", and on the rolling (already-exists) path it only PATCHes name/body — it never moves the tag.

Why this matters

We roll out a single canonical release workflow to every hero_* repo. It builds each branch and publishes to a per-branch rolling release:

branch	tag	should be
main	`latest-main`	stable
development	`latest-development`	pre-release
integration	`latest-integration`	pre-release

Because of the two hardcodes:

Wrong commit. latest-main on hero_proc ended up anchored to a development commit (ce2f199) instead of the main tip. Every repo would hit this — the release never points at the commit it was built from.
No pre-releases. development / integration can't be marked as pre-releases, so everything shows up as stable.

To work around it today, the workflow hand-rolls a git push -f of the tag plus a curl PATCH of the prerelease flag after every build. That logic belongs in lab, not copied into 43 repos' CI.

Reference workflow (the consumer): hero_proc/.forgejo/workflows/lab-publish.yaml

Requested changes

crates/lab/src/repo/releases.rs

ensure_release() / upload_release_assets(): take prerelease: bool and target_commitish: &str instead of hardcoding them; use them in both the create and patch JSON bodies.
Add an anchor_tag() helper that force-moves the rolling tag onto the built commit (the PATCH API can't move an existing tag):
```
git push -f https://oauth2:<TOKEN>@<host>/<owner>/<repo>.git <sha>:refs/tags/<tag>
```
Run it before upload so the create-POST binds to the correctly-placed tag.

Wiring

crates/lab/src/main.rs: add #[arg(long)] prerelease: bool to the Build command and carry it through.
crates/lab/src/builder/orchestrator.rs: repo_root, release_tag, and (forge_url, token, owner, repo) are already in scope. Resolve HEAD (git -C <repo_root> rev-parse HEAD), call anchor_tag(...) once, and pass prerelease + the sha down into the upload.

End result (clean CI)

The whole "anchor tag + set prerelease" CI step disappears; the build step becomes just:

PRE=""; [ "$GITHUB_REF_NAME" = main ] || PRE="--prerelease"
lab build --release --platforms linux-musl-x86_64 --upload --workspace \
  --release-tag "latest-$GITHUB_REF_NAME" $PRE

#317 — install.sh ignores the fetched branch (same rollout; fixed in-workflow with --branch).

## Summary `lab build --upload` needs two small improvements so release publishing is correct and CI stays clean: 1. **Add a `--prerelease` flag.** 2. **Anchor the release tag to the commit being built** (the rolling tag must follow the branch tip). Right now both are hardcoded in [`crates/lab/src/repo/releases.rs`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/main/crates/lab/src/repo/releases.rs): - `ensure_release()` always sends `"prerelease": false`. - On **create** it always sends `"target_commitish": "development"`, and on the rolling (already-exists) path it only PATCHes name/body — it **never moves the tag**. ## Why this matters We roll out a single canonical release workflow to every `hero_*` repo. It builds each branch and publishes to a per-branch rolling release: | branch | tag | should be | |---|---|---| | main | `latest-main` | stable | | development | `latest-development` | pre-release | | integration | `latest-integration` | pre-release | Because of the two hardcodes: - **Wrong commit.** `latest-main` on `hero_proc` ended up anchored to a **development** commit (`ce2f199`) instead of the main tip. Every repo would hit this — the release never points at the commit it was built from. - **No pre-releases.** `development` / `integration` can't be marked as pre-releases, so everything shows up as stable. To work around it today, the workflow hand-rolls a `git push -f` of the tag plus a `curl PATCH` of the `prerelease` flag after every build. That logic belongs in `lab`, not copied into 43 repos' CI. Reference workflow (the consumer): [`hero_proc/.forgejo/workflows/lab-publish.yaml`](https://forge.ourworld.tf/lhumina_code/hero_proc/src/branch/main/.forgejo/workflows/lab-publish.yaml) ## Requested changes **`crates/lab/src/repo/releases.rs`** - `ensure_release()` / `upload_release_assets()`: take `prerelease: bool` and `target_commitish: &str` instead of hardcoding them; use them in both the create and patch JSON bodies. - Add an `anchor_tag()` helper that force-moves the rolling tag onto the built commit (the PATCH API can't move an existing tag): ``` git push -f https://oauth2:<TOKEN>@<host>/<owner>/<repo>.git <sha>:refs/tags/<tag> ``` Run it before upload so the create-POST binds to the correctly-placed tag. **Wiring** - `crates/lab/src/main.rs`: add `#[arg(long)] prerelease: bool` to the `Build` command and carry it through. - `crates/lab/src/builder/orchestrator.rs`: `repo_root`, `release_tag`, and `(forge_url, token, owner, repo)` are already in scope. Resolve `HEAD` (`git -C <repo_root> rev-parse HEAD`), call `anchor_tag(...)` once, and pass `prerelease` + the sha down into the upload. ## End result (clean CI) The whole "anchor tag + set prerelease" CI step disappears; the build step becomes just: ```bash PRE=""; [ "$GITHUB_REF_NAME" = main ] || PRE="--prerelease" lab build --release --platforms linux-musl-x86_64 --upload --workspace \ --release-tag "latest-$GITHUB_REF_NAME" $PRE ``` ## Related - #317 — `install.sh` ignores the fetched branch (same rollout; fixed in-workflow with `--branch`).