Implement CI/CD Pipeline #1

New Issue

PeterNashaat · 2025-11-19T08:48:41Z

PeterNashaat commented

2025-11-19 08:48:41 +00:00

CI/CD Pipeline implementation with gitea actions

PeterNashaat self-assigned this 2025-11-19 08:48:41 +00:00

PeterNashaat added this to the hero weeks project 2025-11-19 08:48:41 +00:00

PeterNashaat commented

2025-11-19 18:57:07 +00:00

I’ve Created a new branch main_cicdpipeline that adds a proper CI + Release pipeline for the Horus repo using Gitea Actions.

What’s added

CI workflow (ci.yml)
- Runs on branch pushes and PRs (release tags v*.*.* are ignored).
- Discovers all crates under bin/ via find bin -name Cargo.toml and, for each one, runs:
  - cargo check, cargo test, cargo clippy, and cargo build --release.
- Uses RUSTFLAGS="--cap-lints=warn" for check/test steps so “warnings as errors” in shared crates (like hero-runner) don’t break CI, while Clippy is still strict.
Release workflow (release.yml)
- Triggers on tags matching v*.*.*.
- Builds all binaries in release mode, strips them, and packages:
  supervisor, coordinator, horus, osiris, herorunner, runner_osiris, runner_sal
  into versioned *-<tag>-linux-x86_64.tar.gz tarballs.
- Generates a checksums.txt and publishes a Gitea Release using akkuman/gitea-release-action@v1, attaching all artifacts.

Requirements

The main repo needs a secret called TOKEN_GITEA, which is a Gitea Personal Access Token with repository: Read and Write permission, so the workflow can create/update releases and upload assets.

Once this branch is merged and the secret is set on the main repo, normal pushes/PRs will run CI, and tagging vX.Y.Z will automatically build and publish release artifacts.

I’ve Created a new branch `main_cicdpipeline` that adds a proper CI + Release pipeline for the Horus repo using Gitea Actions. ### What’s added * **CI workflow (`ci.yml`)** * Runs on branch pushes and PRs (release tags `v*.*.*` are ignored). * Discovers all crates under `bin/` via `find bin -name Cargo.toml` and, for each one, runs: * `cargo check`, `cargo test`, `cargo clippy`, and `cargo build --release`. * Uses `RUSTFLAGS="--cap-lints=warn"` for check/test steps so “warnings as errors” in shared crates (like `hero-runner`) don’t break CI, while Clippy is still strict. * **Release workflow (`release.yml`)** * Triggers on tags matching `v*.*.*`. * Builds all binaries in release mode, strips them, and packages: `supervisor`, `coordinator`, `horus`, `osiris`, `herorunner`, `runner_osiris`, `runner_sal` into versioned `*-<tag>-linux-x86_64.tar.gz` tarballs. * Generates a `checksums.txt` and publishes a Gitea Release using `akkuman/gitea-release-action@v1`, attaching all artifacts. ### Requirements * The main repo needs a secret called **`TOKEN_GITEA`**, which is a Gitea Personal Access Token with `repository: Read and Write` permission, so the workflow can create/update releases and upload assets. Once this branch is merged and the secret is set on the main repo, normal pushes/PRs will run CI, and tagging `vX.Y.Z` will automatically build and publish release artifacts.

PeterNashaat commented

2025-11-20 12:12:10 +00:00

I’ve updated the release pipeline to build the Horus binaries via the hero-git Docker image instead of using plain cargo build in the workflow.

Added a reusable hero-git image (Ubuntu + V + herolib + entrypoint) and documented it in README.md.
The release.yml job now runs horus_full_install.vsh inside this image, writing all Horus binaries into /root/hero/bin, which is mounted back to the runner.
Those binaries are then packaged into versioned .tar.gz archives and attached to the Gitea release, with checksums generated as well.

This makes the release artifacts come from the same installer flow we use elsewhere, so releases are now aligned with the official herolib install process.

I’ve updated the release pipeline to build the Horus binaries via the `hero-git` Docker image instead of using plain `cargo build` in the workflow. * Added a reusable `hero-git` image (Ubuntu + V + herolib + entrypoint) and documented it in `README.md`. * The `release.yml` job now runs `horus_full_install.vsh` inside this image, writing all Horus binaries into `/root/hero/bin`, which is mounted back to the runner. * Those binaries are then packaged into versioned `.tar.gz` archives and attached to the Gitea release, with checksums generated as well. This makes the release artifacts come from the same installer flow we use elsewhere, so releases are now aligned with the official herolib install process.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: herocode/horus#1