Ship binaries for supported *BSD platforms #111

New issue

Closed

opened 2026-05-01 17:19:24 +00:00 by Gottox · 1 comment

Gottox commented

2026-05-01 17:19:24 +00:00

How to use this feature request

Please describe your first hand experience in a comment to show why you are interested into the same feature.
Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.

First hand experience

Setup a cloud init openbsd vm
Install a golang build environment
Check out the runner's source code
build the runner

Needs and benefits

In forgejo/runner#1135 support for various *BSD systems was added. It would be awesome to have prebuilt binaries for these targets.

Benefit:

No full checkout of the source
faster provisioning of new runners (especially useful with ephemeral runners)
for running in kubernets with kubevirt:
- easier version tracking, binary can be packed into a datavolume
- therefore easy to cache

Feature Description

Forgejo should build *bsd binaries as part of their release.

What needs to happen before a feature request is ready to be implemented?

Users can complete the first step (accumulating first and experience) on their own, even if this feature request did not catch the eye of someone with the necessary skills to implement it. And when it reaches that point, it will stand out and have a much higher chance of being implemented.

A few other users contributed their own first hand experience.
To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective.
Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information.
The "Needs and benefit" and "Feature description" are finalized.
Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change.
This can be done by the author of the issue or anyone else in a followup comment.
The label Stage/Idea is changed to Stage/Ready.
Feature request is created in the repository where the code resides.
Depending on the feature request it can be in Forgejo or Forgejo runner.
A copy/paste of the "Needs and benefit" and "Feature description" should be used, with link to this issue so the developer knows where to find more details if they need to.

### How to use this feature request * Please describe your first hand experience in a comment to show why you are interested into the same feature. * Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue. * Subscribe to receive notifications on status change and new comments. ### First hand experience - Setup a [cloud init openbsd vm](https://bsd-cloud-image.org/) - Install a golang build environment - Check out the runner's source code - build the runner ### Needs and benefits In https://code.forgejo.org/forgejo/runner/pulls/1135 support for various *BSD systems was added. It would be awesome to have prebuilt binaries for these targets. Benefit: - No full checkout of the source - faster provisioning of new runners (especially useful with ephemeral runners) - for running in kubernets with kubevirt: - easier version tracking, binary can be packed into a datavolume - therefore easy to cache ### Feature Description Forgejo should build *bsd binaries as part of their release. ### What needs to happen before a feature request is ready to be implemented? Users can complete the first step (accumulating first and experience) on their own, even if this feature request did not catch the eye of someone with the necessary skills to implement it. And when it reaches that point, it will stand out and have a much higher chance of being implemented. 1. **A few other users contributed their own first hand experience.** To fully grasp the scope of a feature request, and to brainstorm possible solutions, a feature request will generally wait until several users have provided their perspective. Thumbs-up reactions help gauge popularity, but do not provide the same amount of useful information. 1. **The "Needs and benefit" and "Feature description" are finalized.** Results from discussions and additional user experiences are incorporated into a final summary to provide a single reference for the developers working on this change. This can be done by the author of the issue or anyone else in a followup comment. 1. **The label `Stage/Idea` is changed to `Stage/Ready`.** 1. **Feature request is created in the repository where the code resides.** Depending on the feature request it can be in [Forgejo](https://codeberg.org/forgejo/forgejo/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml) or [Forgejo runner](https://code.forgejo.org/forgejo/runner/issues/new?template=.forgejo%2fissue_template%2ffeature-request.yaml). A copy/paste of the "Needs and benefit" and "Feature description" should be used, with link to this issue so the developer knows where to find more details if they need to.

Gottox added the

Stage

Idea

label

2026-05-01 17:19:24 +00:00