Publish versioned binary releases on Forgejo package registry #35

Open
opened 2026-04-01 14:26:40 +00:00 by timur · 1 comment
Owner

Summary

Set up automated binary releases for hero_proc on the Forgejo package registry so downstream consumers (e.g. znzfreezone_vdc node installer) can reliably fetch pinned or latest versions.

Current State

Binaries are published manually at:

https://forge.ourworld.tf/api/packages/lhumina_code/generic/hero_proc/0.4.1/
  hero_proc-linux-amd64
  hero_proc_server-linux-amd64
  hero_proc_ui-linux-amd64

Requested

  • CI workflow that publishes binaries on tag push (e.g. v0.4.2)
  • Always update a latest version alias so consumers can fetch the newest build
  • Include all three binaries: hero_proc, hero_proc_server, hero_proc_ui
  • Cross-compile for x86_64-unknown-linux-musl (static binary, no glibc dependency)
  • SHA256 checksums alongside binaries

Why

The ZNZ Free Zone node installer (znzfreezone_node_installer) needs to download hero_proc binaries at build time or at node initialization. Having a stable latest URL and versioned releases makes this reliable and reproducible.

## Summary Set up automated binary releases for hero_proc on the Forgejo package registry so downstream consumers (e.g. znzfreezone_vdc node installer) can reliably fetch pinned or latest versions. ## Current State Binaries are published manually at: ``` https://forge.ourworld.tf/api/packages/lhumina_code/generic/hero_proc/0.4.1/ hero_proc-linux-amd64 hero_proc_server-linux-amd64 hero_proc_ui-linux-amd64 ``` ## Requested - [ ] CI workflow that publishes binaries on tag push (e.g. `v0.4.2`) - [ ] Always update a `latest` version alias so consumers can fetch the newest build - [ ] Include all three binaries: `hero_proc`, `hero_proc_server`, `hero_proc_ui` - [ ] Cross-compile for `x86_64-unknown-linux-musl` (static binary, no glibc dependency) - [ ] SHA256 checksums alongside binaries ## Why The ZNZ Free Zone node installer (`znzfreezone_node_installer`) needs to download hero_proc binaries at build time or at node initialization. Having a stable `latest` URL and versioned releases makes this reliable and reproducible. ## Related - znzfreezone_vdc: https://forge.ourworld.tf/znzfreezone_code/beacon_znzfreezone/issues/1 - gubuntu-installer: https://forge.ourworld.tf/geomind_code/gubuntu-installer
Owner

This issue's premise is stale. Binaries have been auto-published on v* tag push since at least v0.4.1 (2026-03-25) via .forgejo/workflows/build-linux.yaml. The workflow:

  • Cross-compiles to x86_64-unknown-linux-musl (static-pie)
  • Creates a Forgejo Release on tag
  • Uploads <bin>-linux-amd64 per binary in $BINARIES
  • Also publishes to the package registry at forge.ourworld.tf/api/packages/lhumina_code/generic/hero_proc/<version>/

Verified against v0.4.4: each asset is a real ELF 64-bit … static-pie linked, stripped binary; downloading and running hero_proc --version reports hero_proc 0.4.4 correctly.

The consumer side (service_proc install --from-ci) just landed in hero_skills 3387d28 (PR #193).

What's still missing from the original ask:

  • latest alias — the issue asks for a stable latest URL. Forgejo's API returns the latest release at https://forge.ourworld.tf/api/v1/repos/lhumina_code/hero_proc/releases/latest (used by the new --from-ci resolver) but there's no human-readable releases/latest/... redirect for asset downloads. Worth filing separately if needed by the znzfreezone consumers.
  • SHA256 checksums — not produced today. Worth a follow-up issue, but not blocking the consumer pipeline. TLS handles transport integrity; explicit signing (cosign) is in the hero_demo#54 §Storage section as deferred.
  • Cosmetic: rename build-linux.yamlrelease.yaml to match hero_demo#39's canonical convention. No functional change.

Proposing this issue can be closed — the core ask (auto-publish on tag) is done. Filing the three sub-items above as separate trackers if desired.

Signed-off-by: mik-tf

This issue's premise is stale. Binaries have been auto-published on `v*` tag push since at least [v0.4.1 (2026-03-25)](https://forge.ourworld.tf/lhumina_code/hero_proc/releases/tag/v0.4.1) via `.forgejo/workflows/build-linux.yaml`. The workflow: - Cross-compiles to `x86_64-unknown-linux-musl` (static-pie) - Creates a Forgejo Release on tag - Uploads `<bin>-linux-amd64` per binary in `$BINARIES` - Also publishes to the package registry at `forge.ourworld.tf/api/packages/lhumina_code/generic/hero_proc/<version>/` Verified against [v0.4.4](https://forge.ourworld.tf/lhumina_code/hero_proc/releases/tag/v0.4.4): each asset is a real `ELF 64-bit … static-pie linked, stripped` binary; downloading and running `hero_proc --version` reports `hero_proc 0.4.4` correctly. The consumer side (`service_proc install --from-ci`) just landed in [hero_skills 3387d28](https://forge.ourworld.tf/lhumina_code/hero_skills/commit/3387d28403d9e09b032e0215293f203cc24454d5) (PR [#193](https://forge.ourworld.tf/lhumina_code/hero_skills/pulls/193)). What's still missing from the original ask: - [ ] **`latest` alias** — the issue asks for a stable `latest` URL. Forgejo's API returns the latest release at `https://forge.ourworld.tf/api/v1/repos/lhumina_code/hero_proc/releases/latest` (used by the new `--from-ci` resolver) but there's no human-readable `releases/latest/...` redirect for asset downloads. Worth filing separately if needed by the znzfreezone consumers. - [ ] **SHA256 checksums** — not produced today. Worth a follow-up issue, but not blocking the consumer pipeline. TLS handles transport integrity; explicit signing (cosign) is in the [hero_demo#54](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/54) §Storage section as deferred. - [ ] **Cosmetic: rename `build-linux.yaml` → `release.yaml`** to match [hero_demo#39](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/39)'s canonical convention. No functional change. Proposing this issue can be **closed** — the core ask (auto-publish on tag) is done. Filing the three sub-items above as separate trackers if desired. Signed-off-by: mik-tf
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
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_proc#35
No description provided.