ci(lab-publish): derive release tag from branch (main->latest, development->latest-dev) #76

Merged

sameh-farouk merged 1 commit from development_sameh_ci_release_tag into development

2026-06-07 14:50:39 +00:00

sameh-farouk commented

2026-06-07 13:36:52 +00:00

Member

What

The publish workflow uploaded every push to the latest release, because no --release-tag was passed and lab defaults to latest. That meant development builds clobbered the stable latest release, and v* tag pushes also landed in latest instead of their own versioned release.

This adopts the canonical hero_proc tag logic:

Push	Release tag
`main`	`latest` (stable)
`development`	`latest-dev` (lab marks any `-dev` tag as prerelease)
`v*` tag	the ref name (e.g. `v1.2.3`)

Changes

Add main to the push triggers.
Derive $TAG from GITHUB_REF_NAME via a case block and pass --release-tag "$TAG" to lab build. The flag is supported by the lab installed from hero_skills@development.

Scope note

Kept this repo's local CI specifics (the RUST_MIN_STACK SIGSEGV guard, Rust 1.95, inline git-auth) instead of a verbatim drop-in of the newer canonical file, which also bumps the toolchain to 1.96 and swaps the git-auth step — separate concerns, not required for the tag behavior.

Verification

YAML + bash -n syntax check pass.
Tag derivation simulated: main->latest, development->latest-dev, v1.2.3->v1.2.3. Feature branches don't trigger the workflow, so the *) fallback only ever serves v* tags.

## What The publish workflow uploaded **every** push to the `latest` release, because no `--release-tag` was passed and `lab` defaults to `latest`. That meant `development` builds clobbered the stable `latest` release, and `v*` tag pushes also landed in `latest` instead of their own versioned release. This adopts the canonical hero_proc tag logic: | Push | Release tag | |---|---| | `main` | `latest` (stable) | | `development` | `latest-dev` (lab marks any `-dev` tag as prerelease) | | `v*` tag | the ref name (e.g. `v1.2.3`) | ## Changes - Add `main` to the push triggers. - Derive `$TAG` from `GITHUB_REF_NAME` via a `case` block and pass `--release-tag "$TAG"` to `lab build`. The flag is supported by the lab installed from `hero_skills@development`. ## Scope note Kept this repo's local CI specifics (the `RUST_MIN_STACK` SIGSEGV guard, Rust 1.95, inline git-auth) instead of a verbatim drop-in of the newer canonical file, which also bumps the toolchain to 1.96 and swaps the git-auth step — separate concerns, not required for the tag behavior. ## Verification - YAML + `bash -n` syntax check pass. - Tag derivation simulated: `main->latest`, `development->latest-dev`, `v1.2.3->v1.2.3`. Feature branches don't trigger the workflow, so the `*)` fallback only ever serves `v*` tags.

sameh-farouk added 1 commit

2026-06-07 13:36:52 +00:00

ci(lab-publish): derive release tag from branch (main->latest, development->latest-dev) a803457021

The publish workflow uploaded every push to the `latest` release because no
--release-tag was passed and lab defaults to `latest`. So development builds
clobbered the stable `latest` release, and `v*` tag pushes landed in `latest`
too instead of their own versioned release.

Adopt the canonical hero_proc tag logic:
  - push to main        -> latest      (stable)
  - push to development -> latest-dev  (lab marks any `-dev` tag prerelease)
  - push v* tag         -> the ref name (versioned release)

Add `main` to the push triggers and pass --release-tag "$TAG" (supported by the
lab installed from hero_skills@development). Kept this repo's local CI specifics
(RUST_MIN_STACK SIGSEGV guard, Rust 1.95, inline git-auth) rather than a verbatim
drop-in of the newer canonical file, which also bumps the toolchain and swaps the
git-auth step — separate concerns.