GitHub has slowly become an advertising platform for repos more than anything. I miss what it was just a couple of years ago. It did exactly what you needed when you needed it. Now it’s just so bloated
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.)
What’s wrong w/ actions? Is there something else you prefer?
I think they’re quite powerful. There are a variety of triggers, runners are fairly easy to configure (easy to scale up), and the syntax is pretty straightforward. It seems to work pretty well.
Every other ci in existence you just write a command. Then if it doesn’t work you run the command on your machine and fix it.
Actions are “magic” which means you have to fake the ci runner with tools and reverse engineer the action to run local debugging and if it failed you might not even fully know what was running with digging into the actions source.
GitHub provides you the tools and their “easy” until they aren’t.
It’s very Microsoft though. It feels like trying to write a Windows app and trying to get your random
Net environment definition to line everything up and compile in VS then hoping the same thing happens when you deploy.
You can just write bash scripts in your actions if you want them to be easily replicatable on your local machine, so you don’t really lose anything with that system.
I prefer Gitlab CICD but there are many. Actions had a lot of potential. Then Microsoft bought GitHub and just slapped the Actions label on their CI. If you pull off the mask, it is just Azure devops.
Nice!
I actually recently set up my own Forgejo instance, and it’s remarkably similar to GitHub, to the point where they share Github’s “actions” code.
Congrats! More hosting diversity is a good thing.
Yep I got one too. Works great and self hosted. I swear its actually faster than GH is nowadays.
And I like that it doesn’t try to advertise and recommend a ton of repos to do you like GH does now.
GitHub has slowly become an advertising platform for repos more than anything. I miss what it was just a couple of years ago. It did exactly what you needed when you needed it. Now it’s just so bloated
The releases page is just as easy to find!
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.)
I love that they have scoped labels while GitHub still doesn’t
Oh…I was interested until you said actions. What a terrible system for ci.
What’s wrong w/ actions? Is there something else you prefer?
I think they’re quite powerful. There are a variety of triggers, runners are fairly easy to configure (easy to scale up), and the syntax is pretty straightforward. It seems to work pretty well.
Every other ci in existence you just write a command. Then if it doesn’t work you run the command on your machine and fix it.
Actions are “magic” which means you have to fake the ci runner with tools and reverse engineer the action to run local debugging and if it failed you might not even fully know what was running with digging into the actions source.
GitHub provides you the tools and their “easy” until they aren’t.
It’s very Microsoft though. It feels like trying to write a Windows app and trying to get your random Net environment definition to line everything up and compile in VS then hoping the same thing happens when you deploy.
You can just write bash scripts in your actions if you want them to be easily replicatable on your local machine, so you don’t really lose anything with that system.
I prefer Gitlab CICD but there are many. Actions had a lot of potential. Then Microsoft bought GitHub and just slapped the Actions label on their CI. If you pull off the mask, it is just Azure devops.
I do too. I kinda miss Jenkins but a lot of the conveniences in GitLab’s CI are really nice and it’s better for 99% of use cases.
deleted by creator