forgejo/runner
31
99
Fork
You've already forked runner
 104
Code Issues 36 Pull requests 13 Releases 93 Packages 1 Activity Actions

feat: adding firecracker micro-VM support #1382

Open
adamcharnock wants to merge 2 commits from adamcharnock/runner:pr/firecracker into main
pull from: adamcharnock/runner:pr/firecracker
merge into: forgejo:main
Conversation 6 Commits 2 Files changed 32 +5928 -68
adamcharnock commented 2026-02-16 15:26:15 +00:00
First-time contributor
Copy link

Firstly, I would like to apologise for the size of this PR. This is something we needed internally with some urgency, otherwise we would have engaged in more discussion first. My hope is that it has the redeeming traits of 1) being a separate fairly isolated feature that can be marked as 'experimental' in the release notes, and 2) actually already being used in production (by ourselves).

This was a lot of work to get working, but now it is serving us pretty solidly. I've also taken pains to try to minimize the number of "WTF" moments in the code, but I am sure there are still some there. I would love to get this merged in, but it does mean I need to rely on someone with better knowledge to point out the remaining WTF-points. Once pointed out I will endeavor to fix them!

What this adds

A new firecracker label scheme that runs CI jobs inside per-job Firecracker microVMs. Each job gets an isolated VM with its own filesystem, network, and (via jailer) cgroup memory limits.

Needs either bare metal, or nested virtualization support.

Why?

We development this because of the pains of needing to use both docker and tailscale within our CI workflows. This is relatively easy in VMs, but doing it in containers is somewhere between tricky and impossible.

This also gives:

  • Another layer of GitHub actions compatibility
  • OOM isolation
  • Resource limits and guarantees (currently memory only, but CPU scheduling could be added in future)

Previous work

There was previous discussion of adding Firecracker support in #152, coupled with a design change. This PR keeps the design the same, and starts VMs much like LXC containers. The runner then connects into the VMs via SSH to execute the jobs.

Interesting features

  1. A memory scheduler, so it will not OOM the entire runner server.
  2. Smart enough not to claim jobs it cannot schedule (within current API limitations)
  3. Supports multiple runner sizes (CPU/memory)

There is certainly room for further development, but this was the minimum-viably-useful implementation for our purposes.

Label format

small:firecracker://ubuntu:22.04

Where small maps to a named profile in the runner config:

firecracker:
  kernel_path: /opt/firecracker/vmlinux
  rootfs_template: /opt/firecracker/rootfs.ext4
  profiles:
    small:
      memory_mb: 2048
      vcpus: 2
    large:
      memory_mb: 8192
      vcpus: 4

Workflows then use runs-on: small to select a VM size.

Platform support

Firecracker is Linux-only. The package compiles on all platforms via stub files (firecracker_other.go, memory_other.go) that return clear errors. No existing behaviour is changed on non-Linux systems.

Additional fixes

There are some additional issues that came up while working on firecracker support. There are also in this PR,
but we can likely split them out if needs be (the following 3 points were AI generated, because it is more thorough than I am).

Bug: Cleanup skipped on job timeout

act/runner/job_executor.go:168 — Post-steps (cache save, etc.) only run when a job is canceled, not when it times out. Changed ctx.Err() == context.Canceled to ctx.Err() != nil.

Improvement: Set TERM=dumb

act/runner/run_context.go:1524 — Adds TERM=dumb to job environment. Standard CI practice (GitHub Actions does this). Prevents ANSI escape codes polluting logs.

Code quality: PickLabel() helper

internal/pkg/labels/labels.go:89-100 — New method that finds which label name matches a runs-on value. Used by Firecracker but generic enough to be useful elsewhere.

Adam's AI Transparency Statement

See also: AI Agreement. I have also taken the time to read the proceeding conversation, and the various views shared.

The code within this PR is the result of extensive planning between myself and Opus 4.5, and was written by the same (in this specific case, this was a lot of work). In doing this I exercised my 20+ years of experience as a software & infrastructure engineer to guide this tool with the attention and diligence that I would guide a junior engineer. I stake my name and reputation to the code I am submitting, in the context of whatever comments I have made above.

Every word written in the associated issues and PRs was written by my own hand (unless indicated otherwise). Every sentiment I express is my own.

Regarding licensing, I have consulted with the Anthropic consumer terms, which state:

...to the extent permitted by applicable law, you retain any right, title,
and interest that you have in such Inputs. Subject to your compliance with
our Terms, we assign to you all our right, title, and interest (if any) in Outputs.

I propose this shows that I have made "an effort to verify that you can submit this under the license of the repository", as required by section 2 of the AI Agreement. Moreover, I think it shows that I can indeed do so.

My hope in making this statement is to show that I can responsibly and honestly contribute to the Forgejo project, as I would very much like to continue to do. I will attach this statement to all PRs to which it applies.

I agree to the Forgejo Developer Certificate of Origin. Let me know if there is a formal signing procedure I need to follow.

  • features
    • PR: feat: adding firecracker micro-VM support
Firstly, I would like to apologise for the size of this PR. This is something we needed internally with some urgency, otherwise we would have engaged in more discussion first. My hope is that it has the redeeming traits of 1) being a separate fairly isolated feature that can be marked as 'experimental' in the release notes, and 2) actually already being used in production (by ourselves). **This was a lot of work to get working**, but now it is serving us pretty solidly. I've also taken pains to try to minimize the number of "WTF" moments in the code, but I am sure there are still some there. I would love to get this merged in, but it does mean I need to rely on someone with better knowledge to point out the remaining WTF-points. Once pointed out I will endeavor to fix them! ## What this adds A new `firecracker` label scheme that runs CI jobs inside per-job [Firecracker](https://firecracker-microvm.github.io/) microVMs. Each job gets an isolated VM with its own filesystem, network, and (via jailer) cgroup memory limits. Needs either bare metal, or nested virtualization support. ## Why? We development this because of the pains of needing to use both docker and tailscale within our CI workflows. This is relatively easy in VMs, but doing it in containers is somewhere between tricky and impossible. This also gives: * Another layer of GitHub actions compatibility * OOM isolation * Resource limits and guarantees (currently memory only, but CPU scheduling could be added in future) ## Previous work There was previous discussion of adding Firecracker support in #152, coupled with a design change. This PR keeps the design the same, and starts VMs much like LXC containers. The runner then connects into the VMs via SSH to execute the jobs. ## Interesting features 1. A memory scheduler, so it will not OOM the entire runner server. 2. Smart enough not to claim jobs it cannot schedule (within current API limitations) 3. Supports multiple runner sizes (CPU/memory) There is certainly room for further development, but this was the minimum-viably-useful implementation for our purposes. ### Label format ``` small:firecracker://ubuntu:22.04 ``` Where `small` maps to a named profile in the runner config: ```yaml firecracker: kernel_path: /opt/firecracker/vmlinux rootfs_template: /opt/firecracker/rootfs.ext4 profiles: small: memory_mb: 2048 vcpus: 2 large: memory_mb: 8192 vcpus: 4 ``` Workflows then use runs-on: small to select a VM size. # Platform support Firecracker is Linux-only. The package compiles on all platforms via stub files (firecracker_other.go, memory_other.go) that return clear errors. No existing behaviour is changed on non-Linux systems. # Additional fixes There are some additional issues that came up while working on firecracker support. There are also in this PR, but we can likely split them out if needs be (the following 3 points were AI generated, because it is more thorough than I am). **Bug: Cleanup skipped on job timeout** `act/runner/job_executor.go:168` — Post-steps (cache save, etc.) only run when a job is canceled, not when it times out. Changed `ctx.Err() == context.Canceled to ctx.Err() != nil`. **Improvement: Set TERM=dumb** `act/runner/run_context.go:1524` — Adds `TERM=dumb` to job environment. Standard CI practice (GitHub Actions does this). Prevents ANSI escape codes polluting logs. **Code quality: PickLabel() helper** `internal/pkg/labels/labels.go:89-100` — New method that finds which label name matches a runs-on value. Used by Firecracker but generic enough to be useful elsewhere. --- ## Adam's AI Transparency Statement See also: [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). I have also taken the time to read [the proceeding conversation](https://codeberg.org/forgejo/discussions/issues/366), and the various views shared. The code within this PR is the result of extensive planning between myself and Opus 4.5, and was written by the same (in this specific case, this was **a lot** of work). In doing this I exercised my 20+ years of experience as a software & infrastructure engineer to guide this tool with the attention and diligence that I would guide a junior engineer. I stake my name and reputation to the code I am submitting, in the context of whatever comments I have made above. Every word written in the associated issues and PRs was written by my own hand (unless indicated otherwise). Every sentiment I express is my own. Regarding licensing, I have consulted with the Anthropic [consumer terms](https://www.anthropic.com/legal/consumer-terms), which state: > ...to the extent permitted by applicable law, you retain any right, title, > and interest that you have in such Inputs. Subject to your compliance with > our Terms, we assign to you all our right, title, and interest (if any) in Outputs. I propose this shows that I have made "an effort to verify that you can submit this under the license of the repository", as required by section 2 of the AI Agreement. Moreover, I think it shows that I can indeed do so. My hope in making this statement is to show that I can responsibly and honestly contribute to the Forgejo project, as I would very much like to continue to do. I will attach this statement to all PRs to which it applies. I agree to the Forgejo Developer Certificate of Origin. Let me know if there is a formal signing procedure I need to follow. <!--start release-notes-assistant--> <!--URL:https://code.forgejo.org/forgejo/runner--> - features - [PR](https://code.forgejo.org/forgejo/runner/pulls/1382): <!--number 1382 --><!--line 0 --><!--description ZmVhdDogYWRkaW5nIGZpcmVjcmFja2VyIG1pY3JvLVZNIHN1cHBvcnQ=-->feat: adding firecracker micro-VM support<!--description--> <!--end release-notes-assistant--> 
Add a new Firecracker microVM-based runtime that provides strong
isolation for CI jobs using lightweight virtual machines. Jobs targeting
Firecracker VMs use the `firecracker:` label scheme (e.g.,
`runs-on: firecracker://ubuntu:24.04`).

Key features:
- Per-job Firecracker microVMs with configurable vCPUs and memory
- SSH-based command execution and SCP-based file transfer into VMs
- Memory-aware job scheduling with configurable limits and queuing
- Optional jailer integration for per-VM cgroup isolation
- TAP networking with automatic NAT and subnet management
- Named profiles for different VM sizes (e.g., small, large)
- VM resource usage logging via cgroup stats
- Graceful cleanup of VM resources, network, and cgroups

Configuration is via the `firecracker` section in the runner config
with per-label profiles that map to VM resource allocations.
docs: fix inaccurate defaults and improve Firecracker documentation
Some checks failed
issue-labels / release-notes (pull_request_target) Successful in 10s
Details
checks / Build Forgejo Runner (pull_request) Has been cancelled
Details
checks / Build unsupported platforms (pull_request) Has been cancelled
Details
checks / runner exec tests (pull_request) Has been cancelled
Details
checks / Run integration tests with Docker (docker-latest) (pull_request) Has been cancelled
Details
checks / Run integration tests with Docker (docker-stable) (pull_request) Has been cancelled
Details
checks / Run integration tests with Podman (pull_request) Has been cancelled
Details
checks / validate mocks (pull_request) Has been cancelled
Details
checks / validate pre-commit-hooks file (pull_request) Has been cancelled
Details
c8d49907ca
 
Fix critical inaccuracies: memory scheduling enabled default (was false,
actually true), reserve_mb default (was 2048, actually 4096),
acquire_timeout default (was 5m, actually 1h), and use_jailer default
comment (was false, actually true). Add missing min_job_memory_mb and
jailer_uid/jailer_gid config fields. Improve approachability with
prerequisites, subnet allocation docs, monitoring section, SSH keygen
fallback, network verification commands, and expanded troubleshooting.
mfenniak commented 2026-02-16 16:48:28 +00:00
Owner
Copy link

I'm not sure what you're expecting when you drop a 6000 LOC PR without any participation in discussion about the feature, and without any technical design discussion. Especially considering that contributors (myself included) have expressed clearly in that feature request that we don't believe the current project resources can adequately support the complexity added by another execution backend.

"This is something we needed internally with some urgency" sounds a lot like you've developed this feature and now you want to offload the maintenance to an open source project.

As an experienced engineer, please consider this from my angle, and help me understand what you expect to happen with this PR?

I'm not sure what you're expecting when you drop a 6000 LOC PR without any participation in [discussion about the feature](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/4), and without any technical design discussion. Especially considering that contributors (myself included) have expressed clearly in that feature request that we don't believe the current project resources can adequately support the complexity added by another execution backend. "This is something we needed internally with some urgency" sounds a lot like you've developed this feature and now you want to offload the maintenance to an open source project. As an experienced engineer, please consider this from my angle, and help me understand what you expect to happen with this PR?
adamcharnock commented 2026-02-16 20:15:52 +00:00
Author
First-time contributor
Copy link

Hello @mfenniak,

This PR certainly wasn't submitted with any expectation whatsoever, I'm sorry if that did not come across.

Given we had developed it already, I thought it sensible to present it as something we had. We developed this 100% in the knowledge that if the community did not wish to merge it, then it would fall on us to maintain it. I want to be super clear that at no point did we want to "offload" this. We are totally open to hearing a "no", or a "interesting proof of concept, but needs more thought," or anything else really.

I confess I had not seen the issue you linked to, I had only seen 152 in the forgejo repository where it appeared that there was some interest but that it ultimately didn't go anywhere. I also saw a little interest on HN so wanted to get the PR out as it sounded like something others may have use of, merged or otherwise.

I had hoped that my other discussion would have shown my intention to be a positive and contributing member to this community.

As an experienced engineer, please consider this from my angle, and help me understand what you expect to happen with this PR?

I expected people to contribute whatever they were willing to give on the matter, and no more. We are all volunteers here, after all.

I know I'm new here, but I have been making a strong effort to be receptive to feedback and respond above and beyond what was asked. I started what I think has been a very productive conversation on the environments feature, produced mock-ups, and made narrated demo videos.

Please also consider this from my angle – a new member of the community, who is already clearly responsive to feedback, who then receives fairly hostile and shaming response in a public forum 😢

I of course accept the decision that the community lacks the resources to support another execution backend. If anything this PR may help demonstrate this with its MVP solution of a sizable 6000 LOC.

I do however see there is discussion of a plugin system. I would therefore hope that the presence of this PR could positively contribute to the design of such plugin system in future.

Until then we will maintain an internal fork. Should anyone wish this to be publicly available just let me know and I will see what I can arrange.

Hello @mfenniak, This PR certainly wasn't submitted with any expectation whatsoever, I'm sorry if that did not come across. Given we had developed it already, I thought it sensible to present it as something we had. We developed this 100% in the knowledge that if the community did not wish to merge it, then it would fall on us to maintain it. I want to be super clear that at no point did we want to "offload" this. We are totally open to hearing a "no", or a "interesting proof of concept, but needs more thought," or anything else really. I confess I had not seen the issue you linked to, I had only seen [152 in the forgejo repository](https://codeberg.org/forgejo/discussions/issues/152) where it appeared that there was some interest but that it ultimately didn't go anywhere. I also saw a little interest [on HN](https://news.ycombinator.com/item?id=46950812) so wanted to get the PR out as it sounded like something others may have use of, merged or otherwise. I had hoped [that my other discussion](https://codeberg.org/forgejo/discussions/issues/440) would have shown my intention to be a positive and contributing member to this community. > As an experienced engineer, please consider this from my angle, and help me understand what you expect to happen with this PR? I expected people to contribute whatever they were willing to give on the matter, and no more. We are all volunteers here, after all. I know I'm new here, but I have been making a strong effort to be receptive to feedback and respond above and beyond what was asked. I started what I think has been a very productive conversation on the environments feature, produced mock-ups, and made narrated demo videos. Please also consider this from my angle – a new member of the community, who is already clearly responsive to feedback, who then receives fairly hostile and shaming response in a public forum 😢 --- I of course accept the decision that the community lacks the resources to support another execution backend. If anything this PR may help demonstrate this with its MVP solution of a sizable 6000 LOC. I do however see there is discussion of a plugin system. I would therefore hope that the presence of this PR could positively contribute to the design of such plugin system in future. Until then we will maintain an internal fork. Should anyone wish this to be publicly available just let me know and I will see what I can arrange.
aahlenst commented 2026-02-16 21:41:20 +00:00
Member
Copy link

@adamcharnock wrote in #1382 (comment):

Please also consider this from my angle – a new member of the community, who is already clearly responsive to feedback, who then receives fairly hostile and shaming response in a public forum 😢

I'm not a native speaker and depending on the day and topic I might struggle to phrase things properly. I also don't want to speak for others. When in doubt, please ask.

I appreciate your efforts and your responsiveness. I found the discussion about environments exemplary. I wish it would be like that every time. Unfortunately, this PR did not start well. To a certain extent, it's the project's fault because there's no clear communication what's expected and what should happen before opening a PR. Finding issues is hard because they are scattered all over the place. There are multiple similar issues and it's not reasonable to expect that people do PhD level research before posting something. I prefer if people do things wrong instead of not at all and I'm happy to guide them in the right direction.

The initial PR description had some problems. Not discussing the feature on purpose together with the expressed urgency and the expectation to land this PR can be interpreted as a code drop. I don't point that out to shame you or to assign blame, but to help you figure out where the problem might have originated. From my side, you haven't lost any reputation or standing and I'd be happy if you would continue working with us.

About the PR itself. Again, only speaking for myself.

The feature itself is interesting. As already indicated, it should ultimately be a plug-in. I want to stress that it shouldn't be interpreted as a lack of interest or an effort to get rid of annoying feature requests. Having isolated back-ends helps with testing and maintenance. It should also enable others to extend Forgejo Runner without being dependent on its maintainers.

The PR itself is very useful because it helps shaping a potential plug-in API. Unfortunately, I expect that it won't be easy to get it right. There are many topics in this PR that have to be resolved before it can be turned into a reusable feature. Not because the PR was bad, but because Forgejo Runner didn't have to deal with these things before: SSH, CPU/memory limits, operating system images, extended label configuration (we have identified that need before). Would you be willing to help? If not, this PR by itself is most likely dead. Again, not because it's bad, but because it's unlikely to land as is. Which would be a shame.

While I have worked with various VM technologies in the past, I haven't yet worked with Firecracker. So it will take me some time to get up to speed. Apart from that, I'm currently working on something else, so it might take some weeks before I can offer substantial technical feedback.

On condition that everybody agrees with the general direction and is willing to help: Does anybody have an idea where and how to start? 😅

@adamcharnock wrote in https://code.forgejo.org/forgejo/runner/pulls/1382#issuecomment-78188: > Please also consider this from my angle – a new member of the community, who is already clearly responsive to feedback, who then receives fairly hostile and shaming response in a public forum :cry: I'm not a native speaker and depending on the day and topic I might struggle to phrase things properly. I also don't want to speak for others. When in doubt, please ask. I appreciate your efforts and your responsiveness. I found the discussion about environments exemplary. I wish it would be like that every time. Unfortunately, this PR did not start well. To a certain extent, it's the project's fault because there's no clear communication what's expected and what should happen before opening a PR. Finding issues is hard because they are scattered all over the place. There are multiple similar issues and it's not reasonable to expect that people do PhD level research before posting something. I prefer if people do things wrong instead of not at all and I'm happy to guide them in the right direction. The initial PR description had some problems. Not discussing the feature on purpose together with the expressed urgency and the expectation to land this PR can be interpreted as a code drop. I don't point that out to shame you or to assign blame, but to help you figure out where the problem might have originated. From my side, you haven't lost any reputation or standing and I'd be happy if you would continue working with us. --- About the PR itself. Again, only speaking for myself. The feature itself is interesting. As already [indicated](https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/4), it should ultimately be a plug-in. I want to stress that it shouldn't be interpreted as a lack of interest or an effort to get rid of annoying feature requests. Having isolated back-ends helps with testing and maintenance. It should also enable others to extend Forgejo Runner without being dependent on its maintainers. The PR itself is very useful because it helps shaping a potential plug-in API. Unfortunately, I expect that it won't be easy to get it right. There are many topics in this PR that have to be resolved before it can be turned into a reusable feature. Not because the PR was bad, but because Forgejo Runner didn't have to deal with these things before: SSH, CPU/memory limits, operating system images, extended label configuration (we have identified that need before). Would you be willing to help? If not, this PR by itself is most likely dead. Again, not because it's bad, but because it's unlikely to land as is. Which would be a shame. While I have worked with various VM technologies in the past, I haven't yet worked with Firecracker. So it will take me some time to get up to speed. Apart from that, I'm currently working on something else, so it might take some weeks before I can offer substantial *technical* feedback. On condition that everybody agrees with the general direction and is willing to help: Does anybody have an idea where and how to start? 😅
❤️ 1
adamcharnock commented 2026-02-16 21:45:16 +00:00
Author
First-time contributor
Copy link

Re-reading my PR, I can see that I said "I would love to get this merged in", which I imagine could have come off as pressuring or a wish to offload. If that was the case, I apologize.

My intention was only to indicate enthusiasm, and an overall positive feeling around what we have working here. It was pretty exciting to get it all functioning after quite a while of going around the houses trying to get a lot of different jigsaw pieces to fit together.

6k lines is clearly a lot. FWIW, the bulk of the code (in firecracker/) is about 1500 lines, plus some additions elsewhere. The rest is a lot of tests and documentation.

EDIT: I think we crossed posts @aahlenst – thank you for taking the time. It is late here, and I'll catch up properly in the morning

Re-reading my PR, I can see that I said "I would love to get this merged in", which I imagine could have come off as pressuring or a wish to offload. If that was the case, I apologize. My intention was only to indicate enthusiasm, and an overall positive feeling around what we have working here. It was pretty exciting to get it all functioning after quite a while of going around the houses trying to get a lot of different jigsaw pieces to fit together. 6k lines is clearly a lot. FWIW, the bulk of the code (in `firecracker/`) is about 1500 lines, plus some additions elsewhere. The rest is a lot of tests and documentation. EDIT: I think we crossed posts @aahlenst – thank you for taking the time. It is late here, and I'll catch up properly in the morning
mfenniak commented 2026-02-17 03:18:39 +00:00
Owner
Copy link

I've been very pleased with the discussion, effort, and time put into https://codeberg.org/forgejo/discussions/issues/440, and I absolutely don't want to lose the possibility of a new contributor in the community with ambitious goals. And of course, I'm technically interested in this specific feature as well. Let's figure out a plan forward.

My first thought is that the firecracker support could be maintained in a fork, for the short-to-medium term. This would accomplish a few things:

  • The maintenance burden would be separated, and contributors could opt-in to monitor and help with that burden. In other words, merge conflicts and new firecracker-related issue reports are only the responsibility of @adamcharnock (presumably) and other contributors who are interested in supporting the effort.
  • We can "quantify" the burden, to some extent. Let's say in a month, the number of patches required to maintain compatibility with the mainline runner, and the number of issues raised, would give us some indication of how difficult it is to support the new capability.
  • Merge conflicts may indicate areas where a future plugin interface could be challenging and require special attention. Maybe. I think we'll learn something about a plugin interface, anyway.
  • Community interest could be gauged by interactions with the fork (issues, problems, etc.), which gives us a sense of who is really interested, and how much.

We could host the fork in the forgejo-contrib org in Codeberg, which is an area where Forgejo's Code of Conduct is applied by the moderation team, but no technical maintenance is taken on by Forgejo contributors as a whole.

We can link to the project in various places, such as the runner's README, the Forgejo monthly report, the Forgejo docs, and describe it as an experimental fork. Along with those links, make an explicit request for feedback asking people to share their experience even if it's uninteresting, perhaps onto a pinned issue on the repo.

Overall, I think we'd get the opportunity to learn and defer all other decisions to a time when we've learned more.

I've been very pleased with the discussion, effort, and time put into https://codeberg.org/forgejo/discussions/issues/440, and I absolutely don't want to lose the possibility of a new contributor in the community with ambitious goals. And of course, I'm technically interested in this specific feature as well. Let's figure out a plan forward. My first thought is that the firecracker support could be maintained in a fork, for the short-to-medium term. This would accomplish a few things: - The maintenance burden would be separated, and contributors could opt-in to monitor and help with that burden. In other words, merge conflicts and new firecracker-related issue reports are only the responsibility of @adamcharnock (presumably) and other contributors who are interested in supporting the effort. - We can "quantify" the burden, to some extent. Let's say in a month, the number of patches required to maintain compatibility with the mainline runner, and the number of issues raised, would give us some indication of how difficult it is to support the new capability. - Merge conflicts may indicate areas where a future plugin interface could be challenging and require special attention. Maybe. I think we'll learn something about a plugin interface, anyway. - Community interest could be gauged by interactions with the fork (issues, problems, etc.), which gives us a sense of who is really interested, and how much. We could host the fork in the [forgejo-contrib org](https://codeberg.org/forgejo-contrib/) in Codeberg, which is an area where Forgejo's Code of Conduct is applied by the moderation team, but no technical maintenance is taken on by Forgejo contributors as a whole. We can link to the project in various places, such as the runner's README, the Forgejo monthly report, the Forgejo docs, and describe it as an experimental fork. Along with those links, make an explicit request for feedback asking people to share their experience even if it's uninteresting, perhaps onto a pinned issue on the repo. Overall, I think we'd get the opportunity to learn and defer all other decisions to a time when we've learned more.
adamcharnock commented 2026-02-23 10:18:41 +00:00
Author
First-time contributor
Copy link

Thank you for the responses everyone, I really apprecaite it. I'd be very happy for this to live on as a fork or as a plug-in. My attention has been taken elsewhere over the last week on to some other tasks, and it'll probably stay that way for another week or so, but I will come back here and pick this up.

Until then, I'll occasionally pop in here and drop a comment just to leave things that I am learning about this new system as I go. The first of which is:

Learning: This does not support the containers: directive. Eg:

# DOES NOT WORK with the Fireactions runner.
# Currently it is silently ignored.
runs-on: docker
container:
  image: alpine:3.20
Thank you for the responses everyone, I really apprecaite it. I'd be very happy for this to live on as a fork or as a plug-in. My attention has been taken elsewhere over the last week on to some other tasks, and it'll probably stay that way for another week or so, but I will come back here and pick this up. Until then, I'll occasionally pop in here and drop a comment just to leave things that I am learning about this new system as I go. The first of which is: **Learning:** This does not support the `containers:` directive. Eg: ```yaml # DOES NOT WORK with the Fireactions runner. # Currently it is silently ignored. runs-on: docker container: image: alpine:3.20 ```
👍 1
adamcharnock force-pushed pr/firecracker from 533fffd670
Some checks are pending
Integration tests for the release process / release-simulation (pull_request) Blocked by required conditions
Details
example / docker-build-push-action-in-lxc (pull_request) Blocked by required conditions
Details
/ example-docker-compose (pull_request) Blocked by required conditions
Details
/ example-lxc-systemd (pull_request) Blocked by required conditions
Details
/ example-on-demand (pull_request) Blocked by required conditions
Details
checks / Build Forgejo Runner (pull_request) Blocked by required conditions
Details
checks / Build unsupported platforms (pull_request) Blocked by required conditions
Details
checks / runner exec tests (pull_request) Blocked by required conditions
Details
checks / Run integration tests with Docker (docker-latest) (pull_request) Blocked by required conditions
Details
checks / Run integration tests with Docker (docker-stable) (pull_request) Blocked by required conditions
Details
checks / Run integration tests with Podman (pull_request) Blocked by required conditions
Details
checks / validate mocks (pull_request) Blocked by required conditions
Details
checks / validate pre-commit-hooks file (pull_request) Blocked by required conditions
Details
cascade / debug (pull_request_target) Has been skipped
Details
cascade / forgejo (pull_request_target) Has been skipped
Details
cascade / end-to-end (pull_request_target) Has been skipped
Details
issue-labels / release-notes (pull_request_target) Successful in 5s
Details
to c8d49907ca
Some checks failed
issue-labels / release-notes (pull_request_target) Successful in 10s
Details
checks / Build Forgejo Runner (pull_request) Has been cancelled
Details
checks / Build unsupported platforms (pull_request) Has been cancelled
Details
checks / runner exec tests (pull_request) Has been cancelled
Details
checks / Run integration tests with Docker (docker-latest) (pull_request) Has been cancelled
Details
checks / Run integration tests with Docker (docker-stable) (pull_request) Has been cancelled
Details
checks / Run integration tests with Podman (pull_request) Has been cancelled
Details
checks / validate mocks (pull_request) Has been cancelled
Details
checks / validate pre-commit-hooks file (pull_request) Has been cancelled
Details
2026-04-06 20:22:39 +00:00 Compare
Some checks are pending
issue-labels / release-notes (pull_request_target) Successful in 10s
Details
checks / Build Forgejo Runner (pull_request) Has been cancelled
Required
Details
checks / Build unsupported platforms (pull_request) Has been cancelled
Details
checks / runner exec tests (pull_request) Has been cancelled
Required
Details
checks / Run integration tests with Docker (docker-latest) (pull_request) Has been cancelled
Required
Details
checks / Run integration tests with Docker (docker-stable) (pull_request) Has been cancelled
Required
Details
checks / Run integration tests with Podman (pull_request) Has been cancelled
Required
Details
checks / validate mocks (pull_request) Has been cancelled
Details
checks / validate pre-commit-hooks file (pull_request) Has been cancelled
Details
cascade / *
Required
This pull request has changes conflicting with the target branch.
  • act/container/executions_environment.go
  • act/container/host_environment.go
  • act/runner/job_executor.go
  • act/runner/job_executor_test.go
  • internal/app/cmd/daemon.go
  • internal/app/poll/mocks/Poller.go
  • internal/app/poll/poller_test.go
  • internal/app/run/mocks/RunnerInterface.go
  • internal/app/run/runner.go
  • internal/pkg/config/config.example.yaml
  • internal/pkg/config/config.go
  • internal/pkg/labels/labels_test.go
Some workflows are waiting to be reviewed.
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u pr/firecracker:adamcharnock-pr/firecracker
git switch adamcharnock-pr/firecracker
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
FreeBSD

   
Kind/Breaking
Breaking change that won't be backward compatible

  
Kind/Bug
Something is not working

  
Kind/Chore
It is no fun but it needs to be done, this is a chore.

  
Kind/DependencyUpdate
for pull requests that are created by renovate when updating a dependency

  
Kind/Documentation
Documentation changes

  
Kind/Enhancement
Improve existing functionality

  
Kind/Feature
New functionality

  
Kind/Security
This is security issue

  
Kind/Testing
Issue or pull request related to testing

  
Priority
Critical
 The priority is critical

  
Priority
High
 The priority is high

  
Priority
Low
 The priority is low

  
Priority
Medium
 The priority is medium

  
Reviewed
Confirmed
 Issue has been confirmed

  
Reviewed
Duplicate
 This issue or pull request already exists

  
Reviewed
Invalid
 Invalid issue

  
Reviewed
Won't Fix
 This issue won't be fixed

  
Status
Abandoned
 Somebody has started to work on this but abandoned work

  
Status
Blocked
 Something is blocking this issue or pull request

  
Status
Need More Info
 Feedback is required to reproduce issue or to continue work

  
Windows
Windows ports is an independent project, see https://github.com/Crown0815/Forgejo-runner-windows-builder

  
linux-powerpc64le
powerpc64le

  
linux-riscv64

   
linux-s390x

   
run-end-to-end-tests
Run https://code.forgejo.org/forgejo/end-to-end with a runner compiled from this pull request

  
run-forgejo-tests
Run https://codeberg.org/forgejo/forgejo tests importing the runner from this pull request

  
run-multi-platform-tests
Label a PR for automatic execution of test suite on arm64 architecture.

No labels
FreeBSD
Kind/Breaking
Kind/Bug
Kind/Chore
Kind/DependencyUpdate
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Windows
linux-powerpc64le
linux-riscv64
linux-s390x
run-end-to-end-tests
run-forgejo-tests
run-multi-platform-tests
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
3 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
forgejo/runner!1382
No description provided.