4 ms·

I recently moved over from self-hosting GitLab to instead having Gitea, Nexus and Drone, because the burden of keeping GitLab up to date was cumbersome, given h

I recently moved over from self-hosting GitLab to instead having Gitea, Nexus and Drone, because the burden of keeping GitLab up to date was cumbersome, given how it's such a large and complicated software package. I wrote about it in my blog post "Goodbye GitLab; Hello Gitea, Nexus and Drone": https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... That said, I still find the UI of GitHub and GitLab to be a bit better than Gitea's (the whole organizations/groups navigation feels better), though Gitea is immeasurably more performant when compared to GitLab, especially when the available hardware resources are limited - in the case of 4 GB of RAM being all that I could afford, it's the difference between a really snappy and annoyingly laggy UI. Admittedly, now it's Nexus that loves eating my resources, though for the most part having software like it for managing most of my container images and other packages is pretty cool and worthwhile, though one might also want to explore the alternatives, such as Artifactory or something else. Also, personally I find Drone to be a bit less capable than GitLab CI and its documentation isn't quite as good in comparison - though that's a given, since it's an external tool developed by another company. Though I guess even Jenkins would also be a viable alternative (despite it having certain issues with plugin stability etc.), or many other CI tools, given that Gitea is actually decently supported! In summary, even if there still are a few challenges here and there, the whole setup is a lovely way to self-host your own projects and everything around them in a cost effective manner and whilst also staying in control over your own data. Gitea is an important part of this and overall I'm really glad that we have cool software like it nowadays! At the same time, I'm more than happy to use GitLab or something like it at work, as long as keeping it working nicely, up to date (and paying for the servers) is someone else's responsibility.

Inversechi 4y ago
By Drone do you mean the `0.8` open source version? If you've not tried Woodpecker it built upon the `0.8` code and added lots of nice functionality, has better documentation, and is in active development. https://woodpecker-ci.org/ https://woodpecker-ci.org/
- KronisLV 4y ago
  I mean the currently available 2.X set of versions: https://docs.drone.io/server/provider/gitea/ https://docs.drone.io/server/provider/gitea/ Its source code is also available on GitHub: https://github.com/harness/drone/releases https://github.com/harness/drone/releases Of course, the point about their license is a good one, which definitely has some limitations on what you can do with it: https://github.com/harness/drone/blob/master/LICENSE https://github.com/harness/drone/blob/master/LICENSE (I wish I earnt 5 million $ and this would be a problem I'd have to think about). Thanks for bringing up Woodpecker, though, it also seems like a nice project and the two CI solutions haven't diverged far enough for migrating over from one to another to be too problematic, should that become relevant in the future: https://github.com/woodpecker-ci/woodpecker https://github.com/woodpecker-ci/woodpecker Of course, as I said, some folks might also prefer something like Jenkins or another CI solution. I'm yet to explore most of the packages out there!
qbasic_forever 4y ago
You'll probably be happy to see the 1.17 dev version of gitea (which should be the next major release) actually has an artifact repository built in and it can even host docker images: https://docs.gitea.io/en-us/packages/overview/ https://docs.gitea.io/en-us/packages/overview/ You have to build the branch yourself right now though, despite being in the docs it's not in the release downloads yet. You might be able to get rid of nexus and just use this built in registry.
- KronisLV 4y ago
  That's actually pretty cool to hear! Though a problem that I ran into with GitLab Registry was that sometimes the Docker image cleanup wasn't done properly and old layers kept lingering around and eating a lot of space. I sort of fixed it with some cleanup scripts and the occasional manual actions, but it still was a bit problematic since running out of space was a very real risk. Nexus does appear to have similar issues, should you use it as an intermediary for CI image builds (e.g. tag it with branch-date and tell your cluster to redeploy the image), but at least it has instructions for cleaning it up that work most of the time: https://help.sonatype.com/repomanager3/nexus-repository-administration/repository-management/cleanup-policies#CleanupPolicies-HowDockerRepositoriesUseSpace https://help.sonatype.com/repomanager3/nexus-repository-admi... Personally, I think that using the same software package for storing build artifacts and the source code itself is a bit risky, but maybe Gitea will be able to tackle those challenges with no significant issues!
  - blktiger 4y ago
    It probably depends on the scale of your builds, but I’d agree that it seems like a generally better idea to separate your docker image repositories from your source control.
- jonnycomputer 4y ago
  I just discovered that the latest gitea supports package repositories. I'd like to see something that works for R packages without too much hassle.
mkesper 4y ago
Maintaining Jenkins and its gazillions of plugins is such a hassle I'd never consider it for a new project.
deleted 4y ago
[deleted]
jonnycomputer 4y ago
I wanted to self-host a git server, and because I use gitlab at work, that was my first choice. But the system requirements for gitlab were too heavy for the linode I was running, so I went with gitea. Linode also had a handy install-script to set everything up painlessly. I concur with your overall assessment.
bluehatbrit 4y ago
Mind if I ask how you're hosting this setup, are you using something like k8s or swarm? If so how are you handling persistence, just normal volumes? I imagine if you were to lose data, that'd be pretty bad.
- KronisLV 4y ago
  Currently using Docker Swarm with bind mounts instead of volumes, because they're a bit easier to work with, backup-wise. Infrastructure wise, there are a few VPSes from a local provider (https://www.time4vps.com/?affid=5294 https://www.time4vps.com/?affid=5294 affiliate link), though I've also used DigitalOcean, Hetzner, Scaleway and others in the past, AWS, GCP and Azure would work as well, though would be much more expensive. For executing CI tasks and backing up the data, i have a few servers on my desk (though regular towers with passive cooling, instead of the rack mounted kind), since those are more cost effective, especially storage wise. The actual files are backed up with BackupPC over the network automatically, at a set interval, to another server: https://backuppc.github.io/backuppc/ https://backuppc.github.io/backuppc/ Then, of course, the backup server data is occasionally sent to another server in my local network, just to spread it around more, in case of disk failures or one of the servers shorting out. Admittedly, it's a lot like using regular rsync with cron, although the benefits of BackupPC are being able to really easily restore files, as well as having incremental backups with compression. It is a bit rudimentary as far as handling data goes, but sometimes that's all that you need: https://blog.kronis.dev/tutorials/simple-ways-to-do-backups https://blog.kronis.dev/tutorials/simple-ways-to-do-backups Alternatively, one might also achieve the same result with something like Bacula, Kubernetes with either hostPath or maybe even just a NFS mount. Other folks might prefer something like GlusterFS or a similar distributed storage solution, or something like Longhorn for Kubernetes in particular.
  - ptman 4y ago
    Comparison of free clouds https://paul.totterman.name/posts/free-clouds/ https://paul.totterman.name/posts/free-clouds/
  - bluehatbrit 4y ago

Inversechi 4y ago

By Drone do you mean the `0.8` open source version? If you've not tried Woodpecker it built upon the `0.8` code and added lots of nice functionality, has better documentation, and is in active development. https://woodpecker-ci.org/ https://woodpecker-ci.org/

KronisLV 4y ago
I mean the currently available 2.X set of versions: https://docs.drone.io/server/provider/gitea/ https://docs.drone.io/server/provider/gitea/ Its source code is also available on GitHub: https://github.com/harness/drone/releases https://github.com/harness/drone/releases Of course, the point about their license is a good one, which definitely has some limitations on what you can do with it: https://github.com/harness/drone/blob/master/LICENSE https://github.com/harness/drone/blob/master/LICENSE (I wish I earnt 5 million $ and this would be a problem I'd have to think about). Thanks for bringing up Woodpecker, though, it also seems like a nice project and the two CI solutions haven't diverged far enough for migrating over from one to another to be too problematic, should that become relevant in the future: https://github.com/woodpecker-ci/woodpecker https://github.com/woodpecker-ci/woodpecker Of course, as I said, some folks might also prefer something like Jenkins or another CI solution. I'm yet to explore most of the packages out there!

qbasic_forever 4y ago

You'll probably be happy to see the 1.17 dev version of gitea (which should be the next major release) actually has an artifact repository built in and it can even host docker images: https://docs.gitea.io/en-us/packages/overview/ https://docs.gitea.io/en-us/packages/overview/ You have to build the branch yourself right now though, despite being in the docs it's not in the release downloads yet. You might be able to get rid of nexus and just use this built in registry.

KronisLV 4y ago
That's actually pretty cool to hear! Though a problem that I ran into with GitLab Registry was that sometimes the Docker image cleanup wasn't done properly and old layers kept lingering around and eating a lot of space. I sort of fixed it with some cleanup scripts and the occasional manual actions, but it still was a bit problematic since running out of space was a very real risk. Nexus does appear to have similar issues, should you use it as an intermediary for CI image builds (e.g. tag it with branch-date and tell your cluster to redeploy the image), but at least it has instructions for cleaning it up that work most of the time: https://help.sonatype.com/repomanager3/nexus-repository-administration/repository-management/cleanup-policies#CleanupPolicies-HowDockerRepositoriesUseSpace https://help.sonatype.com/repomanager3/nexus-repository-admi... Personally, I think that using the same software package for storing build artifacts and the source code itself is a bit risky, but maybe Gitea will be able to tackle those challenges with no significant issues!
- blktiger 4y ago
  It probably depends on the scale of your builds, but I’d agree that it seems like a generally better idea to separate your docker image repositories from your source control.
jonnycomputer 4y ago
I just discovered that the latest gitea supports package repositories. I'd like to see something that works for R packages without too much hassle.

mkesper 4y ago

Maintaining Jenkins and its gazillions of plugins is such a hassle I'd never consider it for a new project.

deleted 4y ago

[deleted]

jonnycomputer 4y ago

I wanted to self-host a git server, and because I use gitlab at work, that was my first choice. But the system requirements for gitlab were too heavy for the linode I was running, so I went with gitea. Linode also had a handy install-script to set everything up painlessly. I concur with your overall assessment.

bluehatbrit 4y ago

Mind if I ask how you're hosting this setup, are you using something like k8s or swarm? If so how are you handling persistence, just normal volumes? I imagine if you were to lose data, that'd be pretty bad.

KronisLV 4y ago
Currently using Docker Swarm with bind mounts instead of volumes, because they're a bit easier to work with, backup-wise. Infrastructure wise, there are a few VPSes from a local provider (https://www.time4vps.com/?affid=5294 https://www.time4vps.com/?affid=5294 affiliate link), though I've also used DigitalOcean, Hetzner, Scaleway and others in the past, AWS, GCP and Azure would work as well, though would be much more expensive. For executing CI tasks and backing up the data, i have a few servers on my desk (though regular towers with passive cooling, instead of the rack mounted kind), since those are more cost effective, especially storage wise. The actual files are backed up with BackupPC over the network automatically, at a set interval, to another server: https://backuppc.github.io/backuppc/ https://backuppc.github.io/backuppc/ Then, of course, the backup server data is occasionally sent to another server in my local network, just to spread it around more, in case of disk failures or one of the servers shorting out. Admittedly, it's a lot like using regular rsync with cron, although the benefits of BackupPC are being able to really easily restore files, as well as having incremental backups with compression. It is a bit rudimentary as far as handling data goes, but sometimes that's all that you need: https://blog.kronis.dev/tutorials/simple-ways-to-do-backups https://blog.kronis.dev/tutorials/simple-ways-to-do-backups Alternatively, one might also achieve the same result with something like Bacula, Kubernetes with either hostPath or maybe even just a NFS mount. Other folks might prefer something like GlusterFS or a similar distributed storage solution, or something like Longhorn for Kubernetes in particular.
- ptman 4y ago
  Comparison of free clouds https://paul.totterman.name/posts/free-clouds/ https://paul.totterman.name/posts/free-clouds/
- bluehatbrit 4y ago