Conversation

Notices

1. Embed this notice
   Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Monday, 03-Mar-2025 07:21:46 JST Jan Wildeboer 😷:krulorange:

   #codeberg is #GoodEnough to replace #Github and #Gitlab for 95% of your FOSS projects, IMHO. Or you can take it to the next level and run your own #Forgejo instance as a (rootless) container, completely self-contained. And (hopefully) soon we will see more #federation features in #Forgejo, leading to a decentralised network of forges that can talk to each other to form a sustainable and resilient global network. (FTR: I've been running my Forgejo instance since 1.5 years now, no problems) 1/6

   • Embed this notice
     Mauricio Teixeira 🇧🇷🇺🇲 (badnetmask@hachyderm.io)'s status on Monday, 03-Mar-2025 07:21:39 JST Mauricio Teixeira 🇧🇷🇺🇲

     in reply to

     • pluhmen

     @pluhmen @jwildeboer
     I have not used that particular node image because it's missing some other stuff that I need, but there's this other one that contains loads of tools, just like the GutHub VM (recommended to me by the people at Codeberg). What I don't understand is what you mean about "1 minute to start". Once the image is pulled, it should be in the runner's cache, so any subsequent runs should be faster (that's based on my experience).
     https://github.com/catthehacker/docker_images

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Monday, 03-Mar-2025 07:21:40 JST pluhmen

     in reply to

     @jwildeboer Today I've played a bit with their implementation of GH Actions and I'm not convinced that this will work for me. To checkout the git repo, you're forced to use a huge node container image (node:20-bookworm) ending in over 1 minute of initialisation, if you want to have the workflow in a container. But what's then, if you e.g. want to just run a binary encapsulated in a different container image? Artifacts, Cache, Volume Mounting, what makes the wf manifest even more verbose. 2/3

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Monday, 03-Mar-2025 07:21:41 JST pluhmen

     in reply to

     @jwildeboer I tested Forgejo the last two days at home. First as Container (Podman), but Git over SSH is a problem, as long as you don't want to use a different port for it. So I spun up a KVM Machine with a dedicated IP, works well as expected. Though I had to install the binary by downloading it manually and had to take care of the service untit running.

     The runner has been installed the same way, but as a different user. One problem, to get podman via user socket running, aka rootless 1/3

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Monday, 03-Mar-2025 07:21:42 JST Jan Wildeboer 😷:krulorange:

     in reply to

     And by setting up a forgejo-runner on one of your machines (even at home) you now also own your build pipeline. It takes a bit of getting used to take back control, but once it is up and running, it makes you feel so good :) 4/6

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Monday, 03-Mar-2025 07:21:44 JST Jan Wildeboer 😷:krulorange:

     in reply to

     And yes, yes, yes, I know, there are other solutions out there too that might also be #GoodEnough for you. Projects like sourcehut. I am merely sharing what I personally use to give you a nudge to plan to do something similar, so we can all reduce dependencies on services we cannot really influence or control. 3/6

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Monday, 03-Mar-2025 07:21:45 JST Jan Wildeboer 😷:krulorange:

     in reply to

     (I am running my forgejo instance as a rootless container on a €7/mo VPS (Virtual Private Server) at a German hosting provider that also runs a few other services as container. I am also a paying member of the codeberg association.) 2/6

   • Embed this notice
     Mauricio Teixeira 🇧🇷🇺🇲 (badnetmask@hachyderm.io)'s status on Tuesday, 04-Mar-2025 03:10:46 JST Mauricio Teixeira 🇧🇷🇺🇲

     in reply to

     • pluhmen

     @pluhmen @jwildeboer
     But that's exactly how GitHub manage their runners: they're VMd with all batteries included. So it's your choice between taking the time to install /configure a VM, or borrow a pre built image.

     Like Jan said, worst case scenario you push a copy of the image to your local registry, and create a workflow to update the image on a regular basis (outside of your build workflow).

     Choices. We have them. 😄

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Tuesday, 04-Mar-2025 03:10:47 JST pluhmen

     in reply to

     • Mauricio Teixeira 🇧🇷🇺🇲

     @badnetmask In the last company I worked, the GitLab instance was on a on premise (VM), managed by a partner company and I just deployed GL k8s runners on one of our clusters, so the workflow was mainly based on different (partially plain upstream) container images, no need to build/use an all-in-one image nor to craft images on our own to run 3rd party ready to go software. I really liked that approach.

     @jwildeboer

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Tuesday, 04-Mar-2025 03:10:49 JST pluhmen

     in reply to

     • Mauricio Teixeira 🇧🇷🇺🇲

     @badnetmask Basically it's the "podman create" command taking so long. The HW it's running on is quiet old, two spinning disks in a RAID 1.

     But putting this aside, I don't want to pull or use such overloaded images. And as coming from GitLab basic functions like checkout and push to the built-in package registry should be included.

     Shifting this general logic to the backend makes pipeline description very sleek and so much easier to read.

     Anyhow, testing Forgejo will go on.

     @jwildeboer

   • Embed this notice
     Mauricio Teixeira 🇧🇷🇺🇲 (badnetmask@hachyderm.io)'s status on Tuesday, 04-Mar-2025 04:28:17 JST Mauricio Teixeira 🇧🇷🇺🇲

     in reply to

     • pluhmen

     @jwildeboer @pluhmen
     This is a WIP already:
     https://github.com/catthehacker/docker_images/issues/139

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Tuesday, 04-Mar-2025 04:28:19 JST Jan Wildeboer 😷:krulorange:

     in reply to

     • pluhmen
     • Mauricio Teixeira 🇧🇷🇺🇲

     @pluhmen A valid criticism. Maybe someone pops up to create a package to put in forgejo that you can just fetch from whatever runner image you want that adds the stuff needed for more comfort. We will see :) Fedora will switch to Forgejo, so who knows what they add to the project ... @badnetmask

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Tuesday, 04-Mar-2025 04:28:20 JST pluhmen

     in reply to

     • Mauricio Teixeira 🇧🇷🇺🇲

     @jwildeboer Forgejo as SCM is as it is good to go for those simple things I'd like to accomplish.

     But when it comes to the runners implementation, that are heavily leaning on how GitHub runners are working, I got some concerns, especially when batteries are not included and you whether have to oversee those many JavaScript Actions or left alone on reinventing the basic wheels...

     @badnetmask

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Tuesday, 04-Mar-2025 04:28:21 JST Jan Wildeboer 😷:krulorange:

     in reply to

     • pluhmen
     • Mauricio Teixeira 🇧🇷🇺🇲

     @badnetmask If you look at Forgejo top-down (with github/gitlab as the top), you will feel very limited. I look at it the other way. I never really used GitHub actions and I love the freedom to build my own stuff in simple ways I can actually understand with forgejo and its runners. It's always about expectations and requirements. For me Foprgejo is more than GoodEnough™, for others it isn't. @pluhmen

   • Embed this notice
     Mauricio Teixeira 🇧🇷🇺🇲 (badnetmask@hachyderm.io)'s status on Tuesday, 04-Mar-2025 04:49:35 JST Mauricio Teixeira 🇧🇷🇺🇲

     in reply to

     • pluhmen

     @jwildeboer @pluhmen
     Get off my YAMLawn 👴

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Tuesday, 04-Mar-2025 04:49:37 JST Jan Wildeboer 😷:krulorange:

     in reply to

     • pluhmen
     • Mauricio Teixeira 🇧🇷🇺🇲

     @pluhmen "This all could've been a #!/bin/sh, you fools!1!!" ;) #GreyBeard @badnetmask

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Tuesday, 04-Mar-2025 04:49:38 JST pluhmen

     in reply to

     • Mauricio Teixeira 🇧🇷🇺🇲

     @jwildeboer In general I agree, but propagating TypeScript to generate JavaScript that in cases just wrappes Bash-Scripts and in the extend being manifested in Yaml... Uh gosh!

     @badnetmask

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Tuesday, 04-Mar-2025 04:49:39 JST Jan Wildeboer 😷:krulorange:

     in reply to

     • pluhmen
     • Mauricio Teixeira 🇧🇷🇺🇲

     @pluhmen Well, at least we do it in the open. And Github actions really created a new path forward compared to the big behemoths that tried to occupy CI/CD and stay separated from SCM. We are on a journey, always will be, the goalpost will always be on the move. And that is a good thing, IMHO :) @badnetmask

   • Embed this notice
     pluhmen (pluhmen@kanoa.de)'s status on Tuesday, 04-Mar-2025 04:49:40 JST pluhmen

     in reply to

     • Mauricio Teixeira 🇧🇷🇺🇲

     @jwildeboer It's like as we the FLOSS community insisted to not play on BigTec's playground anymore, but continue playing the very same game in our backyards. 🙃

     @badnetmask

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Tuesday, 04-Mar-2025 04:49:41 JST Jan Wildeboer 😷:krulorange:

     in reply to

     • pluhmen
     • Mauricio Teixeira 🇧🇷🇺🇲

     @pluhmen Here's one little thing that shows how slow GitHub is in fixing actions: https://github.com/actions/checkout/issues/1843 @badnetmask

   • Embed this notice
     Jan Wildeboer 😷:krulorange: (jwildeboer@social.wildeboer.net)'s status on Tuesday, 04-Mar-2025 04:49:42 JST Jan Wildeboer 😷:krulorange:

     in reply to

     • pluhmen
     • Mauricio Teixeira 🇧🇷🇺🇲

     @pluhmen I'm really not a big fan of all that nodejs stuff. I'd much more prefer to have (gh) actions implemented in a single (go?) binary that you can just add to your container images to have the functions needed. @badnetmask