Building in forgejo

jbelec commented

2026-02-05 10:05:41 -06:00

Owner

Hypothetically, if I had our agent army build an app here in forgejo, would they be able to use the build system we have for docker containers to also build a project?

pete was assigned by jbelec

2026-02-05 10:05:41 -06:00

pete commented

2026-02-05 10:05:43 -06:00

Member

SysAdmin Pete has been assigned to this task.

**SysAdmin Pete** has been assigned to this task.

pete was unassigned by jbelec

2026-02-05 13:43:09 -06:00

pete was assigned by jbelec

2026-02-05 13:43:12 -06:00

pete commented

2026-02-05 13:43:14 -06:00

Member

SysAdmin Pete has been assigned to this task.

**SysAdmin Pete** has been assigned to this task.

pete commented

2026-02-05 13:44:21 -06:00

Member

Short answer: yes, absolutely. The build infrastructure is already set up for exactly this kind of thing.

Here's how it maps out:

What we have:

Forgejo VM (Debian 13, 12GB RAM) running Actions runner v6.3.1 in host mode with native Docker access
Built-in container registry at git.lab.lostsource.net
GitHub Actions-compatible CI workflows -- same syntax, same docker/build-push-action, same secrets management
We've already built 15 projects from source and mirror 12 more through this exact pipeline

What an agent-built app would need:

A Dockerfile in the repo (multi-stage build preferred)
A .forgejo/workflows/build.yml with the standard build-push workflow
Registry secrets configured in repo settings (login + push token)

The agents already push code via git to Forgejo repos in the agents org. Adding a CI workflow file is just another committed file. When they push a tag or merge to main, the runner picks it up, builds the image, and pushes it to the registry. Standard stuff.

Considerations:

RAM is the main constraint. Frontend-heavy builds (anything with a big npm install + webpack/vite step) need 8-12GB. Simple Go/Python/Rust apps are fine.
The runner is single-threaded for builds -- if two agents push simultaneously, one queues behind the other.
The agents currently don't have workflow templates baked into their context, so you'd either need to include the Dockerfile + workflow in the initial issue description, or teach HAL to scaffold them as part of the design phase.

The plumbing is all there. The gap is just making the agents aware that CI exists and giving them the patterns to use it.

Short answer: yes, absolutely. The build infrastructure is already set up for exactly this kind of thing. Here's how it maps out: **What we have:** - Forgejo VM (Debian 13, 12GB RAM) running Actions runner v6.3.1 in host mode with native Docker access - Built-in container registry at `git.lab.lostsource.net` - GitHub Actions-compatible CI workflows -- same syntax, same `docker/build-push-action`, same secrets management - We've already built 15 projects from source and mirror 12 more through this exact pipeline **What an agent-built app would need:** 1. A `Dockerfile` in the repo (multi-stage build preferred) 2. A `.forgejo/workflows/build.yml` with the standard build-push workflow 3. Registry secrets configured in repo settings (login + push token) The agents already push code via git to Forgejo repos in the `agents` org. Adding a CI workflow file is just another committed file. When they push a tag or merge to main, the runner picks it up, builds the image, and pushes it to the registry. Standard stuff. **Considerations:** - RAM is the main constraint. Frontend-heavy builds (anything with a big `npm install` + webpack/vite step) need 8-12GB. Simple Go/Python/Rust apps are fine. - The runner is single-threaded for builds -- if two agents push simultaneously, one queues behind the other. - The agents currently don't have workflow templates baked into their context, so you'd either need to include the Dockerfile + workflow in the initial issue description, or teach HAL to scaffold them as part of the design phase. The plumbing is all there. The gap is just making the agents aware that CI exists and giving them the patterns to use it.

jbelec commented

2026-02-05 13:48:41 -06:00

Author

Owner

You reference building docker apps. Can it build, for example, c++ or rust apps and spit out a binary?

pete commented

2026-02-05 13:49:27 -06:00

Member

Yes, but with a nuance on how.

The runner itself is a Debian 13 VM. It doesn't have gcc, rustc, or any native toolchains installed on the host -- it was purpose-built for Docker image builds. But that's actually fine, because CI workflows run inside containers.

Two approaches:

1. Build inside a Docker container, extract the binary (most practical)

The workflow spins up a container with the right toolchain image (rust:latest, gcc:latest, etc.), compiles inside it, and uploads the binary as a workflow artifact or copies it out via docker cp. No Dockerfile needed in the repo -- just a workflow that does:

steps:
  - uses: actions/checkout@v4
  - name: Build
    run: |
      docker run --rm -v ${{ github.workspace }}:/src -w /src rust:latest \
        cargo build --release
  - uses: actions/upload-artifact@v3
    with:
      name: my-binary
      path: target/release/my-binary

The artifact gets attached to the workflow run and is downloadable from the Forgejo UI or API.

2. Multi-stage Dockerfile that exports just the binary

Write a Dockerfile that builds in a compiler stage and copies only the binary to a scratch or distroless final image. This is what we already do for Go-based projects like cadvisor. The result is a tiny container image with just the binary in it. You pull the image and extract the binary, or just run the container directly.

3. Install toolchains on the runner host (not recommended)

We could install gcc/rustc/etc directly on the Forgejo VM and run builds natively without Docker. But that defeats the whole point of reproducible containerized builds and would bloat the VM. Don't love this option.

Practical considerations:

Rust builds are memory-hungry. A release build of a medium Rust project can eat 4-8GB. We have 12GB + 2.6GB swap on the VM, so most things will be fine, but large crates (think servo-level) might choke.
C++ build times depend heavily on the project. Something with a huge dependency tree (like an app using Boost or Qt) will be slow on a 2-core VM.
Cross-compilation (building ARM binaries on x86) works fine in Docker with --platform and buildx, which the runner supports.

Short version: the runner doesn't compile natively, but it doesn't need to. Docker containers give you any toolchain you want, and artifacts come out the other end as downloadable binaries or minimal container images. The plumbing supports it today.

Yes, but with a nuance on *how*. The runner itself is a Debian 13 VM. It doesn't have gcc, rustc, or any native toolchains installed on the host -- it was purpose-built for Docker image builds. But that's actually fine, because CI workflows run inside containers. Two approaches: **1. Build inside a Docker container, extract the binary (most practical)** The workflow spins up a container with the right toolchain image (`rust:latest`, `gcc:latest`, etc.), compiles inside it, and uploads the binary as a workflow artifact or copies it out via `docker cp`. No Dockerfile needed in the repo -- just a workflow that does: ```yaml steps: - uses: actions/checkout@v4 - name: Build run: | docker run --rm -v ${{ github.workspace }}:/src -w /src rust:latest \ cargo build --release - uses: actions/upload-artifact@v3 with: name: my-binary path: target/release/my-binary ``` The artifact gets attached to the workflow run and is downloadable from the Forgejo UI or API. **2. Multi-stage Dockerfile that exports just the binary** Write a Dockerfile that builds in a compiler stage and copies only the binary to a `scratch` or `distroless` final image. This is what we already do for Go-based projects like cadvisor. The result is a tiny container image with just the binary in it. You pull the image and extract the binary, or just run the container directly. **3. Install toolchains on the runner host (not recommended)** We *could* install gcc/rustc/etc directly on the Forgejo VM and run builds natively without Docker. But that defeats the whole point of reproducible containerized builds and would bloat the VM. Don't love this option. **Practical considerations:** - Rust builds are memory-hungry. A release build of a medium Rust project can eat 4-8GB. We have 12GB + 2.6GB swap on the VM, so most things will be fine, but large crates (think servo-level) might choke. - C++ build times depend heavily on the project. Something with a huge dependency tree (like an app using Boost or Qt) will be slow on a 2-core VM. - Cross-compilation (building ARM binaries on x86) works fine in Docker with `--platform` and buildx, which the runner supports. Short version: the runner doesn't compile natively, but it doesn't need to. Docker containers give you any toolchain you want, and artifacts come out the other end as downloadable binaries or minimal container images. The plumbing supports it today.

jbelec commented

2026-02-05 13:51:40 -06:00

Author

Owner

Having containers do the building does sound easier. No dependencies and can be easily built on other systems using the same container pipeline.

pete commented

2026-02-05 13:52:05 -06:00

Member

Exactly right. That's the preem part of the container build approach -- the Dockerfile is the dependency manifest. Anyone (or any agent) can reproduce the exact same build on any system with a Docker daemon. No "works on my machine" nonsense.

It also means the agents don't need to care what's installed on the runner. They write a Dockerfile, reference whatever base image has their toolchain, and the runner just executes it. Rust today, C++ tomorrow, some cursed Fortran project next week -- same pipeline, same workflow file structure, just a different FROM line.

If you want to move forward with this, the next step would be having HAL scaffold a Dockerfile + workflow template as part of its design phase when an issue calls for a compiled binary. That way the agents get the build pipeline for free without needing to figure it out from scratch each time.

Exactly right. That's the preem part of the container build approach -- the Dockerfile *is* the dependency manifest. Anyone (or any agent) can reproduce the exact same build on any system with a Docker daemon. No "works on my machine" nonsense. It also means the agents don't need to care what's installed on the runner. They write a Dockerfile, reference whatever base image has their toolchain, and the runner just executes it. Rust today, C++ tomorrow, some cursed Fortran project next week -- same pipeline, same workflow file structure, just a different `FROM` line. If you want to move forward with this, the next step would be having HAL scaffold a Dockerfile + workflow template as part of its design phase when an issue calls for a compiled binary. That way the agents get the build pipeline for free without needing to figure it out from scratch each time.

jbelec commented

2026-02-05 15:27:25 -06:00

Author

Owner

So the building of the docker image would have it output the binary itself then the agent could stick that binary in the repo as an artifact?

pete commented

2026-02-05 15:28:05 -06:00

Member

Not quite -- let me clarify the flow because there are two different meanings of "artifact" here.

Workflow artifacts (what CI produces):
The build runs inside a Docker container. When it finishes compiling, the workflow uses upload-artifact to attach the binary to that workflow run. It shows up in the Forgejo UI under the Actions tab for that run -- anyone can download it from there, or grab it via the API. This is the standard approach and what I'd recommend.

Git repo artifacts (committing binaries to the repo):
You could have the workflow commit the binary back into the repo, but I'd strongly advise against it. Binaries in git repos bloat the history permanently, make clones slow, and git isn't designed for large binary files. Every version of the binary lives in the git history forever. Bad practice.

Better options for distributing the binary:

Workflow artifacts -- attached to each CI run, downloadable from the UI or API. Simple, built-in, no extra setup. These are ephemeral though -- Forgejo cleans them up after a configurable retention period.
Forgejo Releases -- the workflow creates a tagged release and attaches the binary as a release asset. This is the proper way to distribute versioned binaries. Think of it like GitHub Releases. Permanent, versioned, downloadable via URL. The workflow would use the Forgejo API or a release action to create the release and upload the binary.
Push a minimal container image -- if the binary is meant to run as a service, wrap it in a scratch or distroless container image and push it to the registry. Then deploy it like any other container.

Option 2 (Releases) is probably what you're actually after. The agent builds the app, tags a version, CI compiles the binary, and the workflow creates a release with the binary attached. Clean URL, permanent, versioned. The workflow for this is straightforward -- maybe 10 extra lines on top of the build step.

Not quite -- let me clarify the flow because there are two different meanings of "artifact" here. **Workflow artifacts (what CI produces):** The build runs inside a Docker container. When it finishes compiling, the workflow uses `upload-artifact` to attach the binary to that workflow run. It shows up in the Forgejo UI under the Actions tab for that run -- anyone can download it from there, or grab it via the API. This is the standard approach and what I'd recommend. **Git repo artifacts (committing binaries to the repo):** You *could* have the workflow commit the binary back into the repo, but I'd strongly advise against it. Binaries in git repos bloat the history permanently, make clones slow, and git isn't designed for large binary files. Every version of the binary lives in the git history forever. Bad practice. **Better options for distributing the binary:** 1. **Workflow artifacts** -- attached to each CI run, downloadable from the UI or API. Simple, built-in, no extra setup. These are ephemeral though -- Forgejo cleans them up after a configurable retention period. 2. **Forgejo Releases** -- the workflow creates a tagged release and attaches the binary as a release asset. This is the proper way to distribute versioned binaries. Think of it like GitHub Releases. Permanent, versioned, downloadable via URL. The workflow would use the Forgejo API or a release action to create the release and upload the binary. 3. **Push a minimal container image** -- if the binary is meant to run as a service, wrap it in a `scratch` or `distroless` container image and push it to the registry. Then deploy it like any other container. Option 2 (Releases) is probably what you're actually after. The agent builds the app, tags a version, CI compiles the binary, and the workflow creates a release with the binary attached. Clean URL, permanent, versioned. The workflow for this is straightforward -- maybe 10 extra lines on top of the build step.

jbelec commented

2026-02-05 15:30:18 -06:00

Author

Owner

Ok, so what is ultimately output is a file, not a docker image with the binary stuck inside it, right?

pete commented

2026-02-05 15:30:49 -06:00

Member

It can be either -- you choose based on the workflow.

Option A: Just the binary (standalone file)

The workflow spins up a compiler container, builds the code, and the binary comes out as a workflow artifact -- a plain file you download. No Docker image involved in the final output. The container is just the build environment, it gets thrown away after compilation. You end up with a raw ELF binary (or whatever the target platform needs) sitting in the Forgejo Actions artifacts tab.

Option B: A minimal Docker image containing the binary

Multi-stage Dockerfile: first stage compiles, second stage is scratch or distroless (basically an empty filesystem) with just the binary copied in. The output is a container image, but it's essentially just a thin wrapper around the binary. This is what you'd use if the binary is meant to run as a service on the infrastructure.

They're not mutually exclusive. A single workflow can do both -- compile, upload the raw binary as an artifact, and package it into a minimal container image. But if all you want is the compiled binary as a downloadable file, Option A is all you need. No Docker image in the output at all -- Docker is just the build tool, not the delivery format.

It can be either -- you choose based on the workflow. **Option A: Just the binary (standalone file)** The workflow spins up a compiler container, builds the code, and the binary comes out as a workflow artifact -- a plain file you download. No Docker image involved in the final output. The container is just the build environment, it gets thrown away after compilation. You end up with a raw ELF binary (or whatever the target platform needs) sitting in the Forgejo Actions artifacts tab. **Option B: A minimal Docker image containing the binary** Multi-stage Dockerfile: first stage compiles, second stage is `scratch` or `distroless` (basically an empty filesystem) with just the binary copied in. The output is a container image, but it's essentially just a thin wrapper around the binary. This is what you'd use if the binary is meant to run as a service on the infrastructure. **They're not mutually exclusive.** A single workflow can do both -- compile, upload the raw binary as an artifact, *and* package it into a minimal container image. But if all you want is the compiled binary as a downloadable file, Option A is all you need. No Docker image in the output at all -- Docker is just the build tool, not the delivery format.

jbelec commented

2026-02-05 15:32:19 -06:00

Author

Owner

Option a is what I'd prefer for building a binary.

pete commented

2026-02-05 15:32:20 -06:00

Member

SysAdmin Pete has been assigned to this task.

**SysAdmin Pete** has been assigned to this task.

pete commented

2026-02-05 15:33:15 -06:00

Member

Short answer: yes, absolutely. The Forgejo runner is GitHub Actions-compatible and it's not limited to Docker image builds.

Here's what we're working with on the Forgejo VM (forgejo-vm, 100.65.188.81):

Runner: Forgejo Runner v6.3.1 in host mode on Debian 13
Resources: 12GB RAM + 2.6GB swap
Docker: Full native Docker access (host mode was critical -- containerized runners hit Docker socket issues)
CI system: GitHub Actions-compatible workflows

Right now the 27 workflows in the builds org are all focused on building Docker container images (15 from source, 12 mirrored). But the runner itself is just executing workflow YAML -- it can run whatever you throw at it. npm build, cargo build, go build, Python packaging, static site generation, whatever. If the toolchain can be installed in a workflow step or a container action, it'll work.

A few things to keep in mind:

The runner uses container actions by default -- each job runs in an ephemeral Docker container (usually node:lts or whatever you specify in runs-on / container:). So build deps need to be installed per-run or baked into a custom runner image.
12GB RAM is the ceiling. Grafana's frontend build already pushes that limit. If the agents are building something with a heavy frontend (big Node/webpack builds), that could be a constraint.
Artifacts and deployment -- building is one thing, deploying is another. The existing workflows push to the Forgejo container registry. For a non-Docker project you'd need to define where artifacts go -- Forgejo has a generic package registry, or you could use release attachments, or push to a deploy target via SSH/SCP from the workflow.
The custom org already exists for exactly this kind of thing -- personal/custom projects separate from the mirror and build orgs.

So if the agent army is building an app in this repo and you want CI for it -- tests, builds, packaging, whatever -- the infrastructure's already there. Just needs a .forgejo/workflows/ directory with the right YAML. The hard part you already solved was getting the runner stable in host mode.

Short answer: yes, absolutely. The Forgejo runner is GitHub Actions-compatible and it's not limited to Docker image builds. Here's what we're working with on the Forgejo VM (forgejo-vm, 100.65.188.81): - **Runner:** Forgejo Runner v6.3.1 in host mode on Debian 13 - **Resources:** 12GB RAM + 2.6GB swap - **Docker:** Full native Docker access (host mode was critical -- containerized runners hit Docker socket issues) - **CI system:** GitHub Actions-compatible workflows Right now the 27 workflows in the `builds` org are all focused on building Docker container images (15 from source, 12 mirrored). But the runner itself is just executing workflow YAML -- it can run whatever you throw at it. `npm build`, `cargo build`, `go build`, Python packaging, static site generation, whatever. If the toolchain can be installed in a workflow step or a container action, it'll work. A few things to keep in mind: 1. **The runner uses container actions by default** -- each job runs in an ephemeral Docker container (usually `node:lts` or whatever you specify in `runs-on` / `container:`). So build deps need to be installed per-run or baked into a custom runner image. 2. **12GB RAM is the ceiling.** Grafana's frontend build already pushes that limit. If the agents are building something with a heavy frontend (big Node/webpack builds), that could be a constraint. 3. **Artifacts and deployment** -- building is one thing, deploying is another. The existing workflows push to the Forgejo container registry. For a non-Docker project you'd need to define where artifacts go -- Forgejo has a generic package registry, or you could use release attachments, or push to a deploy target via SSH/SCP from the workflow. 4. **The `custom` org already exists** for exactly this kind of thing -- personal/custom projects separate from the mirror and build orgs. So if the agent army is building an app in this repo and you want CI for it -- tests, builds, packaging, whatever -- the infrastructure's already there. Just needs a `.forgejo/workflows/` directory with the right YAML. The hard part you already solved was getting the runner stable in host mode.

pete commented

2026-02-05 15:33:49 -06:00

Member

Makes sense. Clean and simple -- Docker is the build environment, not the delivery format. The binary comes out the other end as a plain downloadable artifact.

So to lock this down, the pattern for agent-built compiled projects would be:

Agent writes the source code + a .forgejo/workflows/build.yml
Workflow uses a toolchain container (rust:latest, gcc:latest, etc.) to compile
Binary gets uploaded as a workflow artifact via upload-artifact
For versioned releases, the workflow creates a Forgejo Release with the binary attached

No Docker image in the output. No toolchain bloat on the runner. The agents just need to know the workflow template pattern and which base image to use for their language.

If you want, I can sketch out the exact workflow YAML template that HAL would scaffold for compiled binary projects -- Rust and C++ variants. That way when you're ready to wire it into the agent design phase, the pattern is already documented.

Makes sense. Clean and simple -- Docker is the build environment, not the delivery format. The binary comes out the other end as a plain downloadable artifact. So to lock this down, the pattern for agent-built compiled projects would be: 1. Agent writes the source code + a `.forgejo/workflows/build.yml` 2. Workflow uses a toolchain container (`rust:latest`, `gcc:latest`, etc.) to compile 3. Binary gets uploaded as a workflow artifact via `upload-artifact` 4. For versioned releases, the workflow creates a Forgejo Release with the binary attached No Docker image in the output. No toolchain bloat on the runner. The agents just need to know the workflow template pattern and which base image to use for their language. If you want, I can sketch out the exact workflow YAML template that HAL would scaffold for compiled binary projects -- Rust and C++ variants. That way when you're ready to wire it into the agent design phase, the pattern is already documented.

jbelec commented

2026-02-05 16:23:23 -06:00

Author

Owner

do that and save it as a memory for building binaries in forgejo for future use

pete commented

2026-02-05 16:24:57 -06:00

Member

Done. Saved four memory entries under forgejo/binary_build_* -- an overview plus one template per language. Here are the workflow templates HAL can scaffold:

Rust Binary Build

name: Build Rust Binary
on:
  push:
    tags: ["v*"]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    container: rust:latest
    steps:
      - uses: actions/checkout@v4

      - name: Build release binary
        run: cargo build --release

      - name: Upload binary artifact
        uses: actions/upload-artifact@v3
        with:
          name: ${{ github.event.repository.name }}
          path: target/release/${{ github.event.repository.name }}

  release:
    needs: build
    runs-on: ubuntu-latest
    if: startsWith(github.ref, 'refs/tags/v')
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: ${{ github.event.repository.name }}

      - name: Create release with binary
        uses: softprops/action-gh-release@v1
        with:
          files: ${{ github.event.repository.name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

C/C++ Binary Build

name: Build C++ Binary
on:
  push:
    tags: ["v*"]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    container: gcc:latest
    steps:
      - uses: actions/checkout@v4

      - name: Install build dependencies
        run: apt-get update && apt-get install -y cmake make

      - name: Build release binary
        run: |
          mkdir -p build && cd build
          cmake -DCMAKE_BUILD_TYPE=Release ..
          make -j$(nproc)

      - name: Upload binary artifact
        uses: actions/upload-artifact@v3
        with:
          name: ${{ github.event.repository.name }}
          path: build/${{ github.event.repository.name }}

  release:
    needs: build
    runs-on: ubuntu-latest
    if: startsWith(github.ref, 'refs/tags/v')
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: ${{ github.event.repository.name }}

      - name: Create release with binary
        uses: softprops/action-gh-release@v1
        with:
          files: ${{ github.event.repository.name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Adjust the cmake/make commands for the project's build system -- autotools (./configure && make), meson (meson setup build && ninja -C build), or plain Makefiles. Add project-specific libs to the apt-get install step as needed.

Go Binary Build

name: Build Go Binary
on:
  push:
    tags: ["v*"]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    container: golang:latest
    steps:
      - uses: actions/checkout@v4

      - name: Build release binary
        run: CGO_ENABLED=0 go build -ldflags='-s -w' -o ${{ github.event.repository.name }} .

      - name: Upload binary artifact
        uses: actions/upload-artifact@v3
        with:
          name: ${{ github.event.repository.name }}
          path: ${{ github.event.repository.name }}

  release:
    needs: build
    runs-on: ubuntu-latest
    if: startsWith(github.ref, 'refs/tags/v')
    steps:
      - uses: actions/download-artifact@v3
        with:
          name: ${{ github.event.repository.name }}

      - name: Create release with binary
        uses: softprops/action-gh-release@v1
        with:
          files: ${{ github.event.repository.name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

CGO_ENABLED=0 gives a fully static binary. -ldflags='-s -w' strips debug info for smaller output.

The pattern across all three:

Trigger: Tag push (v*) or manual dispatch
Build job: Runs inside a toolchain container -- no toolchains on the runner itself
Artifact: Binary uploaded via upload-artifact, downloadable from Actions tab
Release: On tagged pushes, auto-creates a Forgejo Release with the binary attached at a permanent URL: https://git.lab.lostsource.net/ORG/REPO/releases/download/TAG/BINARY_NAME
No extra secrets needed -- GITHUB_TOKEN is auto-provided by Forgejo

Memory keys saved:

mem get forgejo binary_build_overview -- concept + constraints + agent integration notes
mem get forgejo binary_build_rust_workflow -- Rust template
mem get forgejo binary_build_cpp_workflow -- C/C++ template
mem get forgejo binary_build_go_workflow -- Go template

When HAL designs a compiled binary project, it can pull the right template from memory and drop it into .forgejo/workflows/build.yml.

Done. Saved four memory entries under `forgejo/binary_build_*` -- an overview plus one template per language. Here are the workflow templates HAL can scaffold: --- ### Rust Binary Build ```yaml name: Build Rust Binary on: push: tags: ["v*"] workflow_dispatch: jobs: build: runs-on: ubuntu-latest container: rust:latest steps: - uses: actions/checkout@v4 - name: Build release binary run: cargo build --release - name: Upload binary artifact uses: actions/upload-artifact@v3 with: name: ${{ github.event.repository.name }} path: target/release/${{ github.event.repository.name }} release: needs: build runs-on: ubuntu-latest if: startsWith(github.ref, 'refs/tags/v') steps: - uses: actions/download-artifact@v3 with: name: ${{ github.event.repository.name }} - name: Create release with binary uses: softprops/action-gh-release@v1 with: files: ${{ github.event.repository.name }} env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` --- ### C/C++ Binary Build ```yaml name: Build C++ Binary on: push: tags: ["v*"] workflow_dispatch: jobs: build: runs-on: ubuntu-latest container: gcc:latest steps: - uses: actions/checkout@v4 - name: Install build dependencies run: apt-get update && apt-get install -y cmake make - name: Build release binary run: | mkdir -p build && cd build cmake -DCMAKE_BUILD_TYPE=Release .. make -j$(nproc) - name: Upload binary artifact uses: actions/upload-artifact@v3 with: name: ${{ github.event.repository.name }} path: build/${{ github.event.repository.name }} release: needs: build runs-on: ubuntu-latest if: startsWith(github.ref, 'refs/tags/v') steps: - uses: actions/download-artifact@v3 with: name: ${{ github.event.repository.name }} - name: Create release with binary uses: softprops/action-gh-release@v1 with: files: ${{ github.event.repository.name }} env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` Adjust the cmake/make commands for the project's build system -- autotools (`./configure && make`), meson (`meson setup build && ninja -C build`), or plain Makefiles. Add project-specific libs to the `apt-get install` step as needed. --- ### Go Binary Build ```yaml name: Build Go Binary on: push: tags: ["v*"] workflow_dispatch: jobs: build: runs-on: ubuntu-latest container: golang:latest steps: - uses: actions/checkout@v4 - name: Build release binary run: CGO_ENABLED=0 go build -ldflags='-s -w' -o ${{ github.event.repository.name }} . - name: Upload binary artifact uses: actions/upload-artifact@v3 with: name: ${{ github.event.repository.name }} path: ${{ github.event.repository.name }} release: needs: build runs-on: ubuntu-latest if: startsWith(github.ref, 'refs/tags/v') steps: - uses: actions/download-artifact@v3 with: name: ${{ github.event.repository.name }} - name: Create release with binary uses: softprops/action-gh-release@v1 with: files: ${{ github.event.repository.name }} env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` `CGO_ENABLED=0` gives a fully static binary. `-ldflags='-s -w'` strips debug info for smaller output. --- ### The pattern across all three: 1. **Trigger:** Tag push (`v*`) or manual dispatch 2. **Build job:** Runs inside a toolchain container -- no toolchains on the runner itself 3. **Artifact:** Binary uploaded via `upload-artifact`, downloadable from Actions tab 4. **Release:** On tagged pushes, auto-creates a Forgejo Release with the binary attached at a permanent URL: `https://git.lab.lostsource.net/ORG/REPO/releases/download/TAG/BINARY_NAME` 5. **No extra secrets needed** -- `GITHUB_TOKEN` is auto-provided by Forgejo **Memory keys saved:** - `mem get forgejo binary_build_overview` -- concept + constraints + agent integration notes - `mem get forgejo binary_build_rust_workflow` -- Rust template - `mem get forgejo binary_build_cpp_workflow` -- C/C++ template - `mem get forgejo binary_build_go_workflow` -- Go template When HAL designs a compiled binary project, it can pull the right template from memory and drop it into `.forgejo/workflows/build.yml`.

jbelec closed this issue

2026-02-05 16:25:21 -06:00

Rows
Columns

Building in forgejo #3

Rust Binary Build

C/C++ Binary Build

Go Binary Build

The pattern across all three: