GitLab Fallback Alternative

Operating Systems & Open Source Open Source & Web-Based
1

I was rather concerned to hear that GitLab is exploring a sale as I use it quite heavily for my private code and pipelines, as do some clients of mine.

I would like to have a fallback up my sleeve and be prepared if ens***ification ensues after a sale. Fingers crossed that someone will make a fork that gets maintained if that does become the case, but I would be keen to hear if anyone has experience with an alternative that might be worth investigating? When I google “gitlab alternative” the number one result I got back was Gitea which looks like it has “gitea actions” for their CI/CD solution. Has anyone used this and think that this works well or are there issues? E.g. can you genuinely self-host everything on your own infrastructure, including the pipelines or does it just keep pushing you for some sort of cloud-based/priced solution? Perhaps you know of an even better solution?

1 Like
2

Gitea was also involved in some drama, so people created a hard fork called Forgejo. Here’s some reading:

4 Likes
3

If you’re not already, host your own GitLab. If gitlab goes under or changes things around, you can still run your own version that’s “untainted” by the changes (like licensing changes or what-not). Neither Gogs, Gitea, nor Forgejo even comes close to feature parity with gitlab (they’re also way lighter in return). You can make do with some “add-ons,” like Jenkins (separate your CI/CD pipeline).

It also depends on what you want from a platform. If you’re just hosting your code, stagit or plain git is probably just fine. If you want to open bug tickets and track them, then get something like one of the 3 other stacks mentioned above.

Some things to note:

  • gogs is a 1 man operation (so code quality is probably still holding up good)
  • gitea is a fork of gogs (a long time ago) backed by a company and they develop gitea on github (and they have enterprise versions now)
  • forgejo is a fresh fork of gitea and it’s developed in-house on their own forgejo instance (and is backed by large non-profits, like Codeberg (which also uses forgejo now)

It’s very ironic that gitea is not developed on a gitea instance. I’m personally kinda against software that is not used by their own makers (I actually was clueless until the forgejo fork happened). How does one know it’s a good product and what it’s missing or could be improved, if one is not using their own creation themselves?

There’s also something to be said about minimal software that does 1 thing and does it well. Git is great as a code repository and collaboration platform. Stagit is good for converting that repo info into http, gopher or gemini format. Jenkins and Woodpecker-CI (codeberg utilizes woodpecker) are good for building that code automatically. You can utilize a mailing list, a ticketing platform (znuny?) or even an online or IRL sticky notes board for bug tracking.

If you’re not dependent on a giant monolith like gitlab, then you can always change between them and remove pieces and add new ones and you’re never tied into a vendor’s implementation. If your whole organization is making use of gitlab and suddenly you lose access to it, then you’re SOL. But if gitlab was only your code repo and you had your ci/cd pipelines in jenkins and bug tracking on a mailing list, then gitlab going down wouldn’t really affect you that much.

Heck, if you were using a proprietary bug tracking (idk, jira?), because, idk, they’re really good or something (lmao), but they either went under or they increased your subscription costs, then changing just the bug tracking would be relatively easy. When you have so many moving parts glued together with chewing gum (like gitlab, gitea etc.), then migrating to another platform will be way more difficult, unless the platform has basically a 1:1 migration option (like from gogs to gitea in the beginning, or from gitea to forgejo for now).

As for “gitea actions,” I never used it myself and I doubt even gitea is using it themselves (see above), so I can’t say how good it is. My devs, back when I was a sysadmin for a software company, were very happy with jenkins. And codeberg is happy with woodpecker. I can’t say what will work best for you, you must try them and see for yourself.

You can even automate some things through other means, like detect a git change through, idk, something like entr or when you run a stagit update and you get an RSS update in newsboat / newsraft, to automatically start building the latest git commit from whichever branch that got pushed. That’s some real platform independence right there (since most of these smaller utilities easily run on BSDs).

6 Likes
4

Thanks for the tip, I will have to check that out.

5

Thanks for all that. I am self-hosting GItLab and as you say, I could just not update it if it got taken over with licensing issues etc, but this would only be suitable for some months or a year or so. Knowing that it wasn’t getting maintained would make me think a security exploit would be found that I wouldn’t get a patch for. Thus, I would want an alternative maintained solution. I took a quick look at the forgejo tool and it looks like it may have all that I require. I just need it to hold git repositories, have an issue tracker (with kanban board), and some sort of pipeline tool. I’m only concerned about the fact that it looks like forgejo says that their runner is “alpha quality” and not ready for production on their README. If this is the case, and GitLab CI/CD becomes a problem, then I guess I would have to go back to jenkins, which was a real pain in the butt when I last used it, but not impossible. I confess that I much prefer how GitLab CI/CD is set up, and don’t know of any other open source self hosted CI/CD software.

You raise a really good point that if one uses separate tools for everything, such as for the git codebase, a separate issue tracker, and a separate pipeine tool such as Jenkins, then one has a much easier time adjusting if one of the tools suddenly becomes unusable for whatever reason. One just has to transition that one aspect, rather than completely changing ones toolset/workflow.

At the end of the day, im going to start trying out forgejo and see how I get on, and then check to make sure my Jenkins knowledge/tutorials aren’t too outdated.

1 Like
6

I mentioned Woodpecker-CI in the other message.

1 Like
7

Selfhosting gitlab is excellent idea if you don’t need public access. Just shove it beyond vpn.

If you do need public access, then yeah, security wise it it will be risky business in case of takeover and removal of ce developement.

Our instance was owned, attacker somehow remotely exploited redis to create himself an account and ran some sort of cryptominer via cicd.

We haven’t found any indication that they gained access to underlying vm, but in the end that did not matter much. You cannot trust that machine anymore.

3 Likes
8

:man_facepalming: So you did. Thanks for pointing that out and sorry for not noticing. That does look promising and I will have to check that out. It is nice having tools dedicated to just one thing.

9

Even more of a reason

1 Like
10

Nitpicking time, that expoit does not apply here. We are discussing gitlab. I don’t even think selfhosted github was ever possible.

3 Likes
11

I was thinking more along the lines of trusting in a provider vs self hosting. Not sure if gitlab has the same architecture or exploit

12

Only shared attack surface between them would be git itself, heh.

We got to experience something like this:

And the exploit was probably this:

So just a warning, gitlab is not something you just deploy and touch up only as needed, security proflyaxis is critical. Monthly checks with scheduled update minimum.
And updates are somewhat complicated, no skipping versions is possible, unless you fancy yourself corrupt gitlab instance.

If you see what gitlab-ce installation looks like, you understand what kind of behemoth you are dealing with.

3 Likes
13

This thread is really enlightening. I currently have a half-baked instance of Gitea set up. It’s only half baked because I need to add SSH key support and for that, I need to figure out how I can get a call to a user on my reverse proxy machine to send it back to the actual host of the gitea instance. Though it seems that I ought to switch to forgejo.

2 Likes
14

Gitea actually has really nice documentation on this issue (assuming you are using containers):

This is how I set it up on my gitea instance, and it has been working fine for almost a year. I’m sure it applies to forgejo as well (and probably other containerised apps including the gitlab containers since nothing really depends on gitea specific functionality IIRC).

That said, if I were setting up an instance today I would choose forgejo as well, but I’m not bothered enough to migrate a perfectly working instance at the moment.

15

I tried to set this up once - back when my homelab was a single Linode. Now my homelab setup is more complicated. Linode runs the public-facing infrastructure - it listens for traffic routed there by DNS, handles SSL and TLS, and is an integral piece of the system’s security. It reverse proxies client traffic back to a physical machine in the network corner of my apartment (my stupid landlord put the networking equipment in a corner of the albeit spacious laundry room, but hey, at least it’s Google Fiber whereas most others are signing deals with the likes of Comcast and Wow).

Anyway, I failed to succeed last time. Now, however I also have the added complexity of having two different machines. And SSH is blocked by my firewall on the public facing machine (the Linode). (I know it’s a VM, but it acts almost entirely like a different machine so that is essentially what it is from a computing standpoint). Firewalld only allows an SSH connection to the Linode on a specific subnet - a subnet I’ve created as a Wireguard tunnel. So either I need to figure out how to let a single user on the Linode have SSH connections over any subnet, or continue only letting connections from the Wireguard tunnel’s subnet through. The second option is definitely the more secure one - in more ways than one.

1 Like
16

I’ve set up a Forgejo instance and a Woodpecker instance now. No SSH yet. Also, all of my homelab’s services run in rootless Podman. I still have the ability to use rootless (or rootful) docker left over from the days of my transition. I mounted the rootless docker.sock into the container instead of the rootful Docker daemon like the Woodpecker documentation said to do. I hope that works.

1 Like