Submitted 11 months ago by possiblylinux127@lemmy.zip to selfhosted@lemmy.world
My current picks are Woodpecker CI and Forgejo runners. Anything else that’s lightweight and easy to manage?
I run Forgejo and had issues with woodpecker’s hooks breaking causing workflows to not start. Moved to Forgejo Actions which had it’s own different set of quirks (really just depends on your exact deployment method), but I’m happy with it.
What are the querks?
First of all, I actually do prefer Forgejo Actions over Woodpecker. Once set up, my only problem with it (so far) is almost certainly caused by my infrastructure and isn’t inherent to FA itself. Pecker, on the other hand, is quite a bit easier to set up and better documented, but I had that issue where it would disconnect from Forgejo and need a few buttons pressed to fix.
This one is just FA being weird:
If you want to deploy the Runner using Docker, the documentation is poor at best. From both a security and documentation standpoint, having it in its own VM is better, but you can do Docker. You just have to read and figure out more on your own. Reading through the example deployments from the documentation will eventually lead you to something along the lines of this (which I copy-pasted from my deployment rather than search for again):
forgejo-runner: image: code.forgejo.org/forgejo/runner:6.3.1 restart: always user: 1000:1000 environment: - DOCKER_HOST=tcp://dind:2376 volumes: - runner_cache:/data depends_on: - dind command: >- bash -ec ' forgejo-runner create-runner-file --name runner --instance https://${DOMAIN} --secret ${RUNNER_SECRET}; sed -i -e "s|\"labels\": null|\"labels\": [\"docker:docker://docker.io/node:22-bookworm\", \"ubuntu-latest:docker://ghcr.io/catthehacker/ubuntu:act-latest\"]|" .runner ; forgejo-runner generate-config > config.yml; sed -i -e "s|^ network: \"\"$| network: host|" config.yml ; sed -i -e "s|^ envs:$$| envs:\n DOCKER_HOST: tcp://dind:2376\n CONTAINER_HOST: tcp://dind:2376|" config.yml ; forgejo-runner --config config.yml daemon '
You don’t actually need to do this since you could edit the two config files yourself and bind them to the container. This is just how you automatically generate those files… And it’s dumb, but it works and it means you don’t have to keep track of those files.
This one is probably just my infrastructure: lemmy.world/comment/16093731
If you do go for FA in Docker (or Podman) and need some help, just ask. I’ll post more of my compose and explain my decisions.
I once set up laminar.ohwg.net
It has the special quirks that it’s configured outside the repository and script based. Listening for webhooks from forgejo needs an additional service though. (Like github.com/adnanh/webhook)
Demo: ci.ohwg.net
Saltstack, nixOS, OpenTofu, OpenBao and gitlab ci.yml to glue it all together.
I set up forgejo recently myself and ended up picking woodpecker. Lots of plugins available for standard stuff and relatively flexible. Docker config was easy and it spins up and shuts down docker containers to run the integrations, you can set up limits for number of concurrent jobs, things like that. You could see this as a plus or not, but woodpecker also has settings for secret management outside of the repo - global, repo-scoped, and user-scoped.
I can’t seem to get run on push to work
Strange! Is it an issue with the setup or your woodpecker config file in the repo? Actioning on push is merely configuring steps after:
when: - event: push branch: main
Maybe, but I ended up with Woodpecker for now.
I’m using Concourse CI
We use forgejo at work and the runners usually do the trick. You cab have them run any shell command you want, manage secrets and the syntax is the same as on github.
The Forgejo guys have built this themselves, so I’m aiming to use that (I don’t just yet, because I can’t find the time).
Just to contrast with some of the other comments regarding this, i’ve have a pretty good experience with this. Was fairly simple to setup up some docker-based runnings following their admin guidance. Have set up a couple (One for Codeberg, one for my own Forgejo instance) each via a seperate LXC container on my home lab. Has been relatively simple to administer so far.
The actions format may take some getting used to if not familiar with GitHub’s own actions CI, which if closely emulates, but most of my projects were coming from GitHub anyway.
I’ve tried it with forgejo, the recommended implementation involves spinning a temporary vm to run the integration and deployment processes, quite resource heavy and slow comparatively to the vm I have that’s running forgejo.
I think there’s an option to have the forgejo server itself run the commands without spinning up vms, but it’s not recommended due to security considerations as they’re running with the same privileges as the server - not a concern if you are the only developer connecting to a private instance of forgejo but something to keep in mind.
Its quite complicated to setup as well, just went through the instructions and its a long way from just add to docker and run unfortunately. Would be nice to be able to just get a runner in the same or different docker and it just works easily without a lot of manual setup in Linux of directories and users and pipes etc.
I’m looking at buildbot
You might want to look into: github.com/lab132/buildbot-gitea
Thanks
Cicada is basically the FOSS version of GitHub Actions. Works pretty well, but the setup and admin is definitely more work than you might want when GA is already available.
So you have a link? I was curious since I hadn’t heard of Cicada yet. But what I’ve found so far are two dead projects 😅
johntash@eviltoast.org 11 months ago
If you’re already using forgejo, try forgejo actions first.
Another interesting one is Argo Workflows if you’re using argocd for anything.
scrubbles@poptalk.scrubbles.tech 11 months ago
Seconded. Just use forgejo runners and actions.