Forgejo Actions is definitely not a turnkey idential-to-GitHub solution, but it’s quite similar and for most not-super-complicated setups it’s basically the same (for better or worse, depending on if you like GH’s Actions).
As far as I remember, everything that I need works out of the box, except for Docker. In fact, just about everything Docker is somewhat quirky in Forgejo Actions.
One mildly annoying quirk of Forgejo is that as of current, the token generated for each Actions run is not quite the same as GitHub’s token. For my specific use case, if you want to upload a Docker Image to the package repository, you can not use the standard auto-generated token, which GitHub does allow you to use. Forgejo instead currently requires you generate your own app token and use that instead, as the auto-generated one lacks permissions over packages. (https://codeberg.org/forgejo/forgejo/issues/3571)
Depending on your infrastructure, it might just be impossible to make the various Docker-related actions (such as https://code.forgejo.org/docker/build-push-action) work. As an example, my infrastructure outlined below is one such case where those actions simply do not work.
Bare Metal (Debian 12) /
├─ Rootless Podman/
├─ Forgejo
├─ Forgejo Runner
├─ Podman-in-Podman (Inner Podman also Rootless)/
├─ <Actions Containers Run Here>
* If you use rootful Docker with Docker-in-Docker, those actions will then work as expected. It is just that attempting to make them work with Rootless Podman (at least the version that ships with Debain 12) currently seems to be impossible.
that’s really too bad, I hope that gets resolved soon
that’s a pretty old version of podman (4.3 looks like?); also, why have nested podman? My infra is something like this:
Bare Metal
├─ Rootless Podman
├─ Forgejo
├─ Rootless Forgejo Runner (planning to run on another machine entirely)
├─ <Actions Containers Run Here>
I doubt the extra level of nesting is the issue though. If your issue is networking, then maybe the version of podman is the issue, since they switched out the networking layer in 5.0. I upgraded for a related reason, though I’m still getting some odd issues (mostly w/ the DNS resolver).
I haven’t gotten to cross-compiling just yet, nor have I needed to build a docker image since my projects are very much in the testing phase. But maybe I’ll give it a shot soon, since it’s better to catch these types of issues before it becomes a bigger problem.
I agree that it is quite possibly related to the version of Podman moreso than an inherent issue. I am currently satisfied, however, and have no desire to fiddle with it any more… Or at least until Debian 13 gets released.
My use of PinP is almost entirely for cleanliness. It allows me to more easily wipe the build environment (clear out space, troubleshooting). It also mildly improves security as the ‘untrusted’ actions containers run on a separate environment from the important Forgejo container.
The workaround I use for the premade Docker actions not functioning is to simply install Podman as one of the build steps and use that instead, lol. (Some configuration required, but that’s the gist.)
Forgejo Actions is definitely not a turnkey idential-to-GitHub solution, but it’s quite similar and for most not-super-complicated setups it’s basically the same (for better or worse, depending on if you like GH’s Actions).
As far as I remember, everything that I need works out of the box, except for Docker. In fact, just about everything Docker is somewhat quirky in Forgejo Actions.
One mildly annoying quirk of Forgejo is that as of current, the token generated for each Actions run is not quite the same as GitHub’s token. For my specific use case, if you want to upload a Docker Image to the package repository, you can not use the standard auto-generated token, which GitHub does allow you to use. Forgejo instead currently requires you generate your own app token and use that instead, as the auto-generated one lacks permissions over packages. (https://codeberg.org/forgejo/forgejo/issues/3571)
Depending on your infrastructure, it might just be impossible to make the various Docker-related actions (such as https://code.forgejo.org/docker/build-push-action) work. As an example, my infrastructure outlined below is one such case where those actions simply do not work.
Bare Metal ├─ Rootless Podman ├─ Forgejo ├─ Rootless Forgejo Runner (planning to run on another machine entirely) ├─ <Actions Containers Run Here>I doubt the extra level of nesting is the issue though. If your issue is networking, then maybe the version of podman is the issue, since they switched out the networking layer in 5.0. I upgraded for a related reason, though I’m still getting some odd issues (mostly w/ the DNS resolver).
I haven’t gotten to cross-compiling just yet, nor have I needed to build a docker image since my projects are very much in the testing phase. But maybe I’ll give it a shot soon, since it’s better to catch these types of issues before it becomes a bigger problem.
I agree that it is quite possibly related to the version of Podman moreso than an inherent issue. I am currently satisfied, however, and have no desire to fiddle with it any more… Or at least until Debian 13 gets released.
My use of PinP is almost entirely for cleanliness. It allows me to more easily wipe the build environment (clear out space, troubleshooting). It also mildly improves security as the ‘untrusted’ actions containers run on a separate environment from the important Forgejo container.
The workaround I use for the premade Docker actions not functioning is to simply install Podman as one of the build steps and use that instead, lol. (Some configuration required, but that’s the gist.)