[ci] Green CI on every Hero distribution repo #39

New issue

Open

opened 2026-04-28 12:21:39 +00:00 by mik-tf · 0 comments

mik-tf commented 2026-04-28 12:21:39 +00:00

Owner

Copy link

Goal

Every Hero repo that ships in the distribution has green CI on push to development AND on pull-requests targeting development, so contributors get pass/fail feedback before merge and the org-wide release pipeline (home#187) can be built on a green base.

Gates the release-artifacts P0 in home#187: no point adding release.yaml to a repo whose CI doesn't even build green.

Canonical technique — port the proven pattern, don't redesign

After auditing the 8 already-green repos, hero_router already implements the exact distribution pattern home#187 calls for. The fix for the 20 broken/missing repos is a uniform port of that template, not bespoke debugging per repo.

Two workflow files, one canonical shape

.forgejo/workflows/build.yaml — fires on push to development + every PR targeting development. NO publish.

Reference: hero_agent/.forgejo/workflows/build.yaml (82 lines, reviewed by xmonader).

on:
  push:
    branches:
      - development
  pull_request:
    branches:
      - development
  workflow_dispatch:

Steps: checkout → install Rust → cargo fmt --check → cargo clippy -D warnings → make check → make test-unit → make build. No release upload.

.forgejo/workflows/release.yaml — fires on tag v* push. THIS is the artifact pipeline home#187 needs.

Reference: hero_router/.forgejo/workflows/release.yaml.

on:
  push:
    tags:
      - "v*"
  workflow_dispatch:

Steps: checkout @ tag → install musl-dev → cross-compile to x86_64-unknown-linux-musl (static-pie!) → strip → create Forgejo release → upload each binary in $BINARIES as <BIN>-linux-amd64-musl.

Verified working in production

hero_router v0.2.2 → hero_router-linux-amd64-musl
  ELF 64-bit LSB pie executable, x86-64, static-pie linked, stripped, 8.6 MB

Statically linked → runs on any x86_64 Linux box (Alpine, Ubuntu, Debian, RHEL, TFGrid flist, bare metal). Exactly the "deploy anywhere" target.

Required repo invariants (the contract)

For the canonical workflows to work, each repo needs:

1. buildenv.sh at root exporting BINARIES="bin1 bin2 ..." (release.yaml iterates over this)
2. Makefile with at minimum check, test (or test-unit), build targets
3. Tags follow vX.Y.Z semver (-dev suffix until v1.0)

Workflow conventions for THIS sweep

• Branch name: development_mik_1 per repo. Same name across all repos for consistency. Don't touch development directly.
• Every change lands via PR. PRs trigger CI per the canonical build.yaml; reviewers see green/red before merge.
• Squash-merge once green. Delete branch local + remote after merge.
• Per-PR scope: one repo's CI port. Keep PRs small and reviewable.

Engineering discipline — root-cause every red signal, never paper over

The whole point of green CI is that green = actually works. A green badge on a silently-disabled test is worse than a red badge — it lies. The rule is: when porting the canonical template uncovers a real failure, fix the root cause; don't loosen the check.

Symptom	✅ Right way	❌ Coping (do not do)
cargo clippy -D warnings fails	Fix the warnings. They usually flag real issues (unused vars, dead code, non-idiomatic patterns).	Drop -D warnings from the workflow
cargo fmt --check fails	Run cargo fmt once, commit as a separate prep commit with clear message ("style: cargo fmt") so the CI port PR stays reviewable.	Skip the fmt step
A unit test fails	Diagnose first. If real bug → fix code; if test bug → fix test; if environmental → #[ignore] with a comment + tracker issue explaining why and when.	Comment out / delete the test silently
Compile error from a stale dep	Update the calling code OR pin the dep with a # Reason: ... comment.	Pin without explanation
musl cross-compile fails (some C dep)	Investigate. If a real C library doesn't speak musl (e.g. ONNX runtime), fall back to x86_64-unknown-linux-gnu for that one repo and document why in the workflow header.	Silently switch target
Repo legitimately needs more than the template (e.g. hero_os Dioxus/WASM build needs dx CLI)	Stop, file a separate issue, mark that repo TODO in this checklist. Move on to the next repo.	Hack the template until it appears green

Three commitments

1. No silently-disabled checks. If a step is removed/ignored/loosened, the PR description and a code comment both explain why and link a tracker issue.
2. Tests that fail are real signals. Treat them as bugs, not as obstacles.
3. If a repo can't be ported cleanly, we say so. Better to leave one repo unchecked here with a tracker (hero_X needs follow-up #Y) than to ship a green badge on a broken repo.

Always work against latest origin/development head

Before opening a sweep PR — and again before re-pushing after CI fails — git fetch origin && git rebase origin/development. If a rebase produces conflicts, first check whether the upstream commits already fixed the bug your PR was targeting: another contributor or session may have landed a parallel fix while your branch was open. If so, abort the rebase and close the PR with a comment pointing to the upstream commit, instead of churning through conflicts on a moot diff. (Logged after hero_foundry PR #16 was superseded mid-rebase by PR #15.)

Why this works without slowing us down

• The canonical template is already proven working in two repos (hero_router + hero_agent) — not new territory.
• Most "red" repos are red from trivial drift (deleted script, stale workflow path) — collapse to <100-line PRs.
• The CI itself is the safety net. A bad port goes red on the working branch; we see it before merge.
• One PR per repo keeps blast radius small. A surprise in repo X doesn't touch repo Y.
• Pre-merge audit catches landmines. The hero_skills demo (today) caught 3 real bugs (AIBROKER URL scheme, stale port, cd leak) in pre-merge review of PRs already passing CI — because each PR is a discrete review unit.

Current state — 29 repos audited 2026-04-25

✅ Green on development (8): hero_skills, hero_router, hero_db, hero_browser, hero_whiteboard, hero_voice, hero_agent, hero_archipelagos.

❌ Red on development (15): see checklist below.

❓ Missing CI / never fires on development (5): hero_collab, hero_livekit, hero_logic, hero_office, hero_codescalers.

Out of scope: hero_zero (legacy docker-era — superseded by hero_demo); mycelium_network (different org — geomind_code).

Per-repo work — port the canonical template

For each repo below:

1. Branch from development as development_mik_1.
2. Verify the contract — does buildenv.sh export BINARIES? Does Makefile have check/test/build? Add or fix as needed.
3. Drop in the two workflows (build.yaml + release.yaml) — copy from hero_router/hero_agent, adapt only the binaries list (sourced from buildenv.sh so often no edit needed).
4. Open a PR development_mik_1 → development → pull_request trigger fires → see green/red.
5. Fix any genuine test failures uncovered by running the new CI.
6. Audit ALL workflows in .forgejo/workflows/, not just the one that fires on the PR. Some repos have multiple workflow files (e.g. test.yaml + build-linux.yaml); a single PR run only tells you about the workflows whose triggers match pull_request. Check every YAML file's triggers; verify each fires green on its appropriate event (push to development, PR, tag). Lesson learned from hero_proxy #26 → #27: test.yaml went green on the PR but build-linux.yaml (which only fires on push, not PR) was still red post-merge.
7. Squash-merge once green. Delete branch.
8. Verify post-merge push runs on development are ALL green before declaring done. If multiple workflows fire on push, every one of them must be green.

❌ Red — needs port (15)

• hero_proc — last failed run #365 → fixed by PR #49 (9b13401); CI now green on push + PR
• hero_proxy — fully green: PR #26 restored Makefile (919c391); PR #27 replaced misconfigured build-linux.yaml with canonical release.yaml (797e906). Both push + PR runs green.
• hero_embedder — fixed by PR #19 (6a305a8); 17 clippy warnings + jsonwebtoken dev-dep + inputs: None for new hero_proc_sdk pin + restricted build-linux.yaml to tag-only; CI green on push + PR.
• hero_os — last failed run #479
• hero_osis — last failed run #419
• hero_books — last failed run #647
• hero_code — last failed run #58
• hero_biz — last failed run #165
• hero_aibroker — last failed run #274
• hero_matrixchat — fixed by PR #3 (defde49); deleted 2 stale integration tests (orphaned by SDK refactor — 122 cumulative compile errors), 1 clippy auto-fix, cargo fmt, ported workflow to canonical Hero pattern (was using GitHub-only actions-rs/toolchain@v1 not on Forgejo mirror). Test-coverage gap tracked at hero_matrixchat#2.
• hero_slides — fixed by PR #33 (2ce31c3); converted hero_lib path deps to git deps (was breaking CI because workspace assumed sibling-clone layout) + cargo fmt. Repo now buildable from any clean checkout — supports home#187 release artifacts directly.
• hero_indexer — fixed by PR #15 (1b0d579); 2 real ?-in-closure compile errors fixed in examples + 2 clippy auto-fixes + 5 e2e tests #[ignore]'d (need live stack — tracked at hero_indexer#14) + cargo fmt. Both build.yaml + build-linux.yaml green on push.
• [~] hero_lib_rhai — PARTIAL. lint.yaml green via PR #11 (e69c7b5); tests.yaml still red on every push (real failure, not coping). Tracked at hero_lib_rhai #12 + home#189. Will fully tick when integration tests are fixed.
• hero_foundry — green on development at cc212d3, made green by PR #15 (separate contributor) which restructured seed_data.rs into the new hero_foundry_demo crate, dissolving the em-dash byte-string compile error organically. Our parallel PR #16 (e21bf5b) was rendered moot mid-rebase and closed. Lesson logged below: always rebase against latest origin/development before pushing CI fixes — when a sweep PR conflicts on rebase, check whether development has already moved past the bug.
• hero_demo — last failed run #32

❓ Missing — needs initial setup (5)

• hero_collab
• hero_logic
• hero_office
• hero_codescalers
• hero_livekit (workflows present but never fire on development — investigate triggers)

✅ Already green — verify they match the canonical pattern + add release.yaml where missing

• hero_skills — post-#131 build.yaml is canonical; needs release.yaml added to publish artifacts (gates home#187 P0).
• hero_router — has both workflows; canonical reference.
• hero_db — has 4 workflows including release.yaml; verify they match canonical shape.
• hero_browser — has build + test + build-linux; needs release.yaml.
• hero_whiteboard — only has ci.yml; needs build.yaml + release.yaml in canonical shape.
• hero_voice — has build + build-linux; needs release.yaml.
• hero_agent — has build.yaml (canonical reference); needs release.yaml.
• hero_archipelagos — has build + build-release; verify build-release matches canonical release.yaml shape.

Acceptance criteria

• Every repo in the distribution has both build.yaml and release.yaml matching the canonical pattern
• Every repo's most recent push to development is ✅
• Every repo accepts and runs CI on pull_request events targeting development (publish/release steps gated to push/tag)
• At least one PR per repo demonstrates the green-on-PR signal in practice
• Cutting a vX.Y.Z tag on any Hero repo produces a release with statically-linked Linux binaries as assets (verified by downloading + running)
• home#187 P0 release-artifacts unblocked — pattern is uniform across the org

Notes

• Repos can be tackled in any order; they don't depend on each other for CI.
• Multiple contributors / sessions can work in parallel — one branch per repo (all named development_mik_1), so no conflicts.
• When in doubt, look at hero_router (canonical release.yaml) and hero_agent (canonical build.yaml).
• Some "red" runs may be ancient and the underlying repo just drifted from its CI. The canonical-port fix is often <100 lines (two workflow files).
• The 8 already-green repos still need release.yaml added (verify column above) — that's part of unblocking home#187 P0 too.

Related

• Master prod tracker: home#187 — Hero OS as a versioned nu-shell distribution
• Reference implementations: hero_router (release.yaml + build.yml), hero_agent (build.yaml)
• Most recent example fix: hero_skills #131 + #132
• Phase 2 tracker: home#185

Signed-off-by: mik-tf

---

Originally filed as home#188 on 2026-04-25 by mik-tf — moved to hero_demo as part of consolidating issue tracking.

## Goal Every Hero repo that ships in the distribution has **green CI on push to `development`** AND on **pull-requests targeting `development`**, so contributors get pass/fail feedback before merge and the org-wide release pipeline ([home#187](https://forge.ourworld.tf/lhumina_code/home/issues/187)) can be built on a green base. Gates the release-artifacts P0 in [home#187](https://forge.ourworld.tf/lhumina_code/home/issues/187): no point adding `release.yaml` to a repo whose CI doesn't even build green. ## Canonical technique — port the proven pattern, don't redesign After auditing the 8 already-green repos, **`hero_router` already implements the exact distribution pattern home#187 calls for**. The fix for the 20 broken/missing repos is a **uniform port of that template**, not bespoke debugging per repo. ### Two workflow files, one canonical shape #### `.forgejo/workflows/build.yaml` — fires on push to `development` + every PR targeting `development`. NO publish. Reference: [`hero_agent/.forgejo/workflows/build.yaml`](https://forge.ourworld.tf/lhumina_code/hero_agent/src/branch/development/.forgejo/workflows/build.yaml) (82 lines, reviewed by xmonader). ```yaml on: push: branches: - development pull_request: branches: - development workflow_dispatch: ``` Steps: checkout → install Rust → `cargo fmt --check` → `cargo clippy -D warnings` → `make check` → `make test-unit` → `make build`. No release upload. #### `.forgejo/workflows/release.yaml` — fires on tag `v*` push. THIS is the artifact pipeline home#187 needs. Reference: [`hero_router/.forgejo/workflows/release.yaml`](https://forge.ourworld.tf/lhumina_code/hero_router/src/branch/development/.forgejo/workflows/release.yaml). ```yaml on: push: tags: - "v*" workflow_dispatch: ``` Steps: checkout @ tag → install musl-dev → cross-compile to `x86_64-unknown-linux-musl` (static-pie!) → strip → create Forgejo release → upload each binary in `$BINARIES` as `<BIN>-linux-amd64-musl`. ### Verified working in production ``` hero_router v0.2.2 → hero_router-linux-amd64-musl ELF 64-bit LSB pie executable, x86-64, static-pie linked, stripped, 8.6 MB ``` Statically linked → runs on any x86_64 Linux box (Alpine, Ubuntu, Debian, RHEL, TFGrid flist, bare metal). Exactly the "deploy anywhere" target. ### Required repo invariants (the contract) For the canonical workflows to work, each repo needs: 1. **`buildenv.sh`** at root exporting `BINARIES="bin1 bin2 ..."` (release.yaml iterates over this) 2. **`Makefile`** with at minimum `check`, `test` (or `test-unit`), `build` targets 3. **Tags follow `vX.Y.Z`** semver (`-dev` suffix until v1.0) ## Workflow conventions for THIS sweep - **Branch name: `development_mik_1`** per repo. Same name across all repos for consistency. Don't touch `development` directly. - **Every change lands via PR.** PRs trigger CI per the canonical `build.yaml`; reviewers see green/red before merge. - **Squash-merge once green.** Delete branch local + remote after merge. - **Per-PR scope: one repo's CI port.** Keep PRs small and reviewable. ## Engineering discipline — root-cause every red signal, never paper over The whole point of green CI is that **green = actually works**. A green badge on a silently-disabled test is worse than a red badge — it lies. The rule is: when porting the canonical template uncovers a real failure, **fix the root cause; don't loosen the check**. | Symptom | ✅ Right way | ❌ Coping (do **not** do) | |---------|-----------|-------------------------| | `cargo clippy -D warnings` fails | **Fix the warnings.** They usually flag real issues (unused vars, dead code, non-idiomatic patterns). | Drop `-D warnings` from the workflow | | `cargo fmt --check` fails | **Run `cargo fmt` once**, commit as a separate prep commit with clear message ("style: cargo fmt") so the CI port PR stays reviewable. | Skip the fmt step | | A unit test fails | **Diagnose first.** If real bug → fix code; if test bug → fix test; if environmental → `#[ignore]` **with a comment + tracker issue** explaining why and when. | Comment out / delete the test silently | | Compile error from a stale dep | **Update the calling code OR pin the dep with a `# Reason: ...` comment.** | Pin without explanation | | musl cross-compile fails (some C dep) | **Investigate.** If a real C library doesn't speak musl (e.g. ONNX runtime), fall back to `x86_64-unknown-linux-gnu` for that one repo and **document why** in the workflow header. | Silently switch target | | Repo legitimately needs more than the template (e.g. hero_os Dioxus/WASM build needs `dx` CLI) | **Stop, file a separate issue, mark that repo TODO in this checklist.** Move on to the next repo. | Hack the template until it appears green | ### Three commitments 1. **No silently-disabled checks.** If a step is removed/ignored/loosened, the PR description **and** a code comment both explain why and link a tracker issue. 2. **Tests that fail are real signals.** Treat them as bugs, not as obstacles. 3. **If a repo can't be ported cleanly, we say so.** Better to leave one repo unchecked here with a tracker (`hero_X needs follow-up #Y`) than to ship a green badge on a broken repo. ### Always work against latest `origin/development` head Before opening a sweep PR — and again before re-pushing after CI fails — `git fetch origin && git rebase origin/development`. If a rebase produces conflicts, **first check whether the upstream commits already fixed the bug your PR was targeting**: another contributor or session may have landed a parallel fix while your branch was open. If so, abort the rebase and close the PR with a comment pointing to the upstream commit, instead of churning through conflicts on a moot diff. (Logged after [hero_foundry PR #16](https://forge.ourworld.tf/lhumina_code/hero_foundry/pulls/16) was superseded mid-rebase by [PR #15](https://forge.ourworld.tf/lhumina_code/hero_foundry/pulls/15).) ### Why this works without slowing us down - The canonical template is **already proven working** in two repos (hero_router + hero_agent) — not new territory. - Most "red" repos are red from trivial drift (deleted script, stale workflow path) — collapse to <100-line PRs. - **The CI itself is the safety net.** A bad port goes red on the working branch; we see it before merge. - **One PR per repo** keeps blast radius small. A surprise in repo X doesn't touch repo Y. - **Pre-merge audit catches landmines.** The hero_skills demo (today) caught 3 real bugs (AIBROKER URL scheme, stale port, cd leak) in pre-merge review of PRs already passing CI — because each PR is a discrete review unit. ## Current state — 29 repos audited 2026-04-25 **✅ Green on `development` (8):** `hero_skills`, `hero_router`, `hero_db`, `hero_browser`, `hero_whiteboard`, `hero_voice`, `hero_agent`, `hero_archipelagos`. **❌ Red on `development` (15):** see checklist below. **❓ Missing CI / never fires on `development` (5):** `hero_collab`, `hero_livekit`, `hero_logic`, `hero_office`, `hero_codescalers`. **Out of scope:** `hero_zero` (legacy docker-era — superseded by `hero_demo`); `mycelium_network` (different org — `geomind_code`). ## Per-repo work — port the canonical template For each repo below: 1. Branch from `development` as `development_mik_1`. 2. **Verify the contract** — does `buildenv.sh` export `BINARIES`? Does `Makefile` have `check`/`test`/`build`? Add or fix as needed. 3. **Drop in the two workflows** (build.yaml + release.yaml) — copy from `hero_router`/`hero_agent`, adapt only the binaries list (sourced from `buildenv.sh` so often no edit needed). 4. **Open a PR `development_mik_1 → development`** → `pull_request` trigger fires → see green/red. 5. **Fix any genuine test failures** uncovered by running the new CI. 6. **Audit ALL workflows in `.forgejo/workflows/`, not just the one that fires on the PR.** Some repos have multiple workflow files (e.g. `test.yaml` + `build-linux.yaml`); a single PR run only tells you about the workflows whose triggers match `pull_request`. Check every YAML file's triggers; verify each fires green on its appropriate event (push to development, PR, tag). **Lesson learned from [hero_proxy #26 → #27](https://forge.ourworld.tf/lhumina_code/hero_proxy/pulls/27):** `test.yaml` went green on the PR but `build-linux.yaml` (which only fires on push, not PR) was still red post-merge. 7. **Squash-merge once green.** Delete branch. 8. **Verify post-merge push runs on `development` are ALL green** before declaring done. If multiple workflows fire on push, every one of them must be green. ### ❌ Red — needs port (15) - [x] `hero_proc` — last failed run #365 → fixed by [PR #49](https://forge.ourworld.tf/lhumina_code/hero_proc/pulls/49) (`9b13401`); CI now green on push + PR - [x] `hero_proxy` — fully green: [PR #26](https://forge.ourworld.tf/lhumina_code/hero_proxy/pulls/26) restored Makefile (`919c391`); [PR #27](https://forge.ourworld.tf/lhumina_code/hero_proxy/pulls/27) replaced misconfigured build-linux.yaml with canonical release.yaml (`797e906`). Both push + PR runs green. - [x] `hero_embedder` — fixed by [PR #19](https://forge.ourworld.tf/lhumina_code/hero_embedder/pulls/19) (`6a305a8`); 17 clippy warnings + jsonwebtoken dev-dep + `inputs: None` for new hero_proc_sdk pin + restricted build-linux.yaml to tag-only; CI green on push + PR. - [ ] `hero_os` — last failed run #479 - [ ] `hero_osis` — last failed run #419 - [ ] `hero_books` — last failed run #647 - [ ] `hero_code` — last failed run #58 - [ ] `hero_biz` — last failed run #165 - [ ] `hero_aibroker` — last failed run #274 - [x] `hero_matrixchat` — fixed by [PR #3](https://forge.ourworld.tf/lhumina_code/hero_matrixchat/pulls/3) (`defde49`); deleted 2 stale integration tests (orphaned by SDK refactor — 122 cumulative compile errors), 1 clippy auto-fix, cargo fmt, ported workflow to canonical Hero pattern (was using GitHub-only `actions-rs/toolchain@v1` not on Forgejo mirror). Test-coverage gap tracked at [hero_matrixchat#2](https://forge.ourworld.tf/lhumina_code/hero_matrixchat/issues/2). - [x] `hero_slides` — fixed by [PR #33](https://forge.ourworld.tf/lhumina_code/hero_slides/pulls/33) (`2ce31c3`); converted hero_lib path deps to git deps (was breaking CI because workspace assumed sibling-clone layout) + cargo fmt. Repo now buildable from any clean checkout — supports home#187 release artifacts directly. - [x] `hero_indexer` — fixed by [PR #15](https://forge.ourworld.tf/lhumina_code/hero_indexer/pulls/15) (`1b0d579`); 2 real `?`-in-closure compile errors fixed in examples + 2 clippy auto-fixes + 5 e2e tests `#[ignore]`'d (need live stack — tracked at [hero_indexer#14](https://forge.ourworld.tf/lhumina_code/hero_indexer/issues/14)) + cargo fmt. Both build.yaml + build-linux.yaml green on push. - [~] `hero_lib_rhai` — **PARTIAL.** lint.yaml green via [PR #11](https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/pulls/11) (`e69c7b5`); tests.yaml still red on every push (real failure, not coping). Tracked at [hero_lib_rhai #12](https://forge.ourworld.tf/lhumina_code/hero_lib_rhai/issues/12) + [home#189](https://forge.ourworld.tf/lhumina_code/home/issues/189). Will fully tick when integration tests are fixed. - [x] `hero_foundry` — green on `development` at `cc212d3`, made green by [PR #15](https://forge.ourworld.tf/lhumina_code/hero_foundry/pulls/15) (separate contributor) which restructured `seed_data.rs` into the new `hero_foundry_demo` crate, dissolving the em-dash byte-string compile error organically. Our parallel [PR #16](https://forge.ourworld.tf/lhumina_code/hero_foundry/pulls/16) (`e21bf5b`) was rendered moot mid-rebase and closed. **Lesson logged below: always rebase against latest `origin/development` before pushing CI fixes — when a sweep PR conflicts on rebase, check whether `development` has already moved past the bug.** - [ ] `hero_demo` — last failed run #32 ### ❓ Missing — needs initial setup (5) - [ ] `hero_collab` - [ ] `hero_logic` - [ ] `hero_office` - [ ] `hero_codescalers` - [ ] `hero_livekit` (workflows present but never fire on `development` — investigate triggers) ### ✅ Already green — verify they match the canonical pattern + add release.yaml where missing - [ ] `hero_skills` — post-#131 build.yaml is canonical; **needs `release.yaml` added** to publish artifacts (gates home#187 P0). - [x] `hero_router` — has both workflows; **canonical reference**. - [ ] `hero_db` — has 4 workflows including release.yaml; verify they match canonical shape. - [ ] `hero_browser` — has build + test + build-linux; **needs release.yaml**. - [ ] `hero_whiteboard` — only has ci.yml; **needs build.yaml + release.yaml in canonical shape**. - [ ] `hero_voice` — has build + build-linux; **needs release.yaml**. - [ ] `hero_agent` — has build.yaml (canonical reference); **needs release.yaml**. - [ ] `hero_archipelagos` — has build + build-release; verify build-release matches canonical release.yaml shape. ## Acceptance criteria - [ ] Every repo in the distribution has both `build.yaml` and `release.yaml` matching the canonical pattern - [ ] Every repo's most recent push to `development` is ✅ - [ ] Every repo accepts and runs CI on `pull_request` events targeting `development` (publish/release steps gated to push/tag) - [ ] At least one PR per repo demonstrates the green-on-PR signal in practice - [ ] Cutting a `vX.Y.Z` tag on any Hero repo produces a release with statically-linked Linux binaries as assets (verified by downloading + running) - [ ] [home#187](https://forge.ourworld.tf/lhumina_code/home/issues/187) P0 release-artifacts unblocked — pattern is uniform across the org ## Notes - Repos can be tackled in any order; they don't depend on each other for CI. - Multiple contributors / sessions can work in parallel — one branch per repo (all named `development_mik_1`), so no conflicts. - When in doubt, look at `hero_router` (canonical release.yaml) and `hero_agent` (canonical build.yaml). - Some "red" runs may be ancient and the underlying repo just drifted from its CI. The canonical-port fix is often <100 lines (two workflow files). - The 8 already-green repos still need `release.yaml` added (verify column above) — that's part of unblocking home#187 P0 too. ## Related - Master prod tracker: [home#187](https://forge.ourworld.tf/lhumina_code/home/issues/187) — Hero OS as a versioned nu-shell distribution - Reference implementations: [hero_router](https://forge.ourworld.tf/lhumina_code/hero_router/src/branch/development/.forgejo/workflows) (release.yaml + build.yml), [hero_agent](https://forge.ourworld.tf/lhumina_code/hero_agent/src/branch/development/.forgejo/workflows) (build.yaml) - Most recent example fix: hero_skills [#131](https://forge.ourworld.tf/lhumina_code/hero_skills/pulls/131) + [#132](https://forge.ourworld.tf/lhumina_code/hero_skills/pulls/132) - Phase 2 tracker: [home#185](https://forge.ourworld.tf/lhumina_code/home/issues/185) Signed-off-by: mik-tf --- *Originally filed as [home#188](https://forge.ourworld.tf/lhumina_code/home/issues/188) on 2026-04-25 by mik-tf — moved to hero_demo as part of consolidating issue tracking.*

mik-tf referenced this issue from lhumina_code/home 2026-04-28 12:21:40 +00:00

[ci] Green CI on every Hero distribution repo #188

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

development_mik2

v0.9.3-dev

v0.9.0-dev

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_demo#39

No description provided.