Gitea – a painless self-hosted Git service
gitea.io
gitea.io
I have a wireguard with the server running on a small VPS, which is useful for both ignoring filtering on public wifi and getting into my home network from wherever.
If I do go this route do you have any suggestions with respect to security?
Also, things I want to look at on my home network mostly work fine over ssh (console stuff, git, etc). So I haven't actually gotten around to setting up full routing yet, and use the wireguard endpoint box as an ssh jumphost / bastion (and can forward ports if I do have something to get at that doesn't like to play nice).
A bit less hands-on solution could be something like tailscale.
https://community.torproject.org/onion-services/advanced/cli...
Bitbucket had free private repos for a long time. There were other services as well.
2008: Github launched
2008: Bitbucket launched
2010: Atlassian purchases bitbucket, makes private repos free
2011: Gitlab launched
2014: Gogs (Gitea's predecessor) first public release
2016: Gitea forks from Gogs
So at the very least, bitbucket was established and gitlab was around
I don’t even know why. Just seeing the interface rubs me entirely the wrong way.
Indeed fossil-scm [1], has same interface as Trac (in my view partly inspired by it). Have used Trac for a long time, so can't complain, it works well, its simple and flexible.
git remote add origin https://my.gitea/user/new_repo
git push
# user/new_repo is created as a private repo
And the default setting happens to be private.
hub create -p
What I will often do if I want to instantly mirror something to github:
hub create -p --remote-name=github
It is also less typing.
Another company was famous for this, they used to call it Embrace, Extend, Extinguish
Does github provide the code of their servers that implements the API? Can you self-host it? If not, then it is pretty proprietary.
https://docs.github.com/en/get-started/quickstart/create-a-r...
I wrote about it in my blog post "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.
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-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!
Its source code is also available on GitHub: 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 (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
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!
I concur with your overall assessment.
Infrastructure wise, there are a few VPSes from a local provider (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/ 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
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.
Appreciate the detail around BackupPC as well!
One option would be opting for a more lightweight Kubernetes distro, such as K3s https://k3s.io/ or k0s https://k0sproject.io/ both of which have comparatively smaller resource requirements whilst still being certified and compliant.
Personally, I'd also use something like Portainer, Rancher or Lens, but that's just because I like UIs alongside my CLIs that are nice to look at.
Practically infinite private repos, privacy, automate/customize all you want.
A small example, we create users for our customers in gitea and they are only part of the "customer" organization. This automatically get them access to the "customer" worklog as they access the customer area. So gitea is for us the central identity management.
Now as it happens, I actively don’t want any of that stuff for something I’m hosting for myself for my own projects only. I pretty much just want the parts you’d get in gitweb or cgit, but done better (since neither of those is very good; I run gitweb because I wasn’t impressed with either, but gitweb was easier to patch into a more acceptable shape). Is Gitea capable of being pared down to just this? Is there anything else that fills this niche?
What issues did you have with gitweb? And what stuff did you patch up?
It’s not everything I’d like changed, but it’s everything I have changed.
it was something short, the url too. it was sh or st something.
can anyone get which one I mean?
edit: YES! it's sr.ht. thanks, commenter below this :)
Here is an example pipeline I use to build and deploy Ditzes (my offline/desktop HN client):
https://codeberg.org/ditzes/ditzes/src/commit/410486175a2dea...
I’m considering switching my NW.js app over to Tauri, but I’m a bit hesitant due to the work involved.
There are still some bugs around that are a bit of a hassle to deal with, but only one that is a showstopper for me personally (the back button on the mouse doesn't navigate back), otherwise it works out well for me.
gitea was considerably easier to set up, and much more bulletproof. gitea was much lighter on resources.
We had a use case to be able to mirror thousands of repos. gitlab would fall flat on its face. gitea had no issues.
We turned this over to corporate, and they chose gitlab. gitlab had great sales people.
I experienced the "Try Gitea" service and migrated our TiDB repo https://github.com/pingcap/tidb to it. When I clicked the Activity tab and selected "1 year" period, I found the page loading was so slow, nearly 90s. And I also found that this Activity doesn't have a Cache, I re-selected "1 year" again, and the page loading was nearly the same time.
I guess Gitea uses git command to traverse all the logs for the period every time. Maybe it can use a database to speed up, or like Github only provide at max "1 month" period.
Trying to same on Codeberg, which is a production environment of Gitea, the loading time of the "Activity" page for Codeberg/gitea seems to take ~5 seconds for me. It still seems to lack any sort of caching, but at least it's relatively fast. See https://codeberg.org/Codeberg/gitea/activity/yearly (people might want to be careful hitting that URL over-and-over, in case we ddos the Codeberg folks :/ )
I'd like to be able to get a list what i'm watching and filter it on repo, author, type (issue/pr), and reason like I very often do in github.
There is also no session managment accessible from user side :(
Moreover, we were going through SOC-2 auditing at that time and it is much easier to just store our source code in one of the SaaS option like Github/GitLab/Bitbucket for our auditors to check without having me to screenshot everything for them.
I see why: Gitea is 75%-Golang, 13%-HandleBarsJs GitLab is 85%-Ruby 12%-HTML
Never have a problem with Gitlab, but is RUBY is slow and cpu demand
I will try it !
If you need a git hosting service but "hosting git" isn't your day job, then the alternatives are way more complex than necessary IMO.
[0]: https://github.com/go-gitea/gitea/blob/main/services/webhook...
Among all the possible things to get worked-up about this seems like nothing (unless you are purist that considers including optional functionality to interface with a proprietary-service to be harmful).
The only problem that I've found is that my github repo now shows very little activity which make job hunting harder.
On Gogs it's not configurable and to stop publishing names of all users, including admin account username, it's necessary to either close down the whole service (disable public view of all repos and disable signup) or block certain addresses on proxy level.
Personally I like even MORE basic than gogs or gitea and use this at my own company:
https://git.zx2c4.com/cgit/about/
It's like a single binary packaged up, and a few lines on openbsd httpd to get it running. Pretty sweet!
So Azure AD and the AWS LB handle authentication whilst Gitea only handles authorization.
I have to admit, if the GitHub repo is the main source for issues/PRs, it's a bit of a yellow flag that they're not dogfooding it.
That being said - if I didn't need easy CI support I'd probably be using Gitea instead of GitLab CE - GitLab CE is great but it's a resource hog and feels like it's getting slower over the years.
Here is an issue tracking the migration: https://github.com/go-gitea/gitea/issues/1029
What they really need to do first is copy Gitlab and add support for logging in with Github. Then they could move their repo to gitea without locking out a bunch of contributors (or keep a copy on github and mirror issues/PRs)
Edit: looks like you already can login with github and they're working on migrating their repos to gitea!
If you're using gitlab or gitea you should be able to allow people to login with github accounts. I used that to raise issues about borgmatic[1] and it was very painless. I believe it's also mirrored on github but issues aren't enabled. Not sure how the maintainer set it up.
[1] https://projects.torsion.org/borgmatic-collective/borgmatic
Happy user of fossil since over 10 years now, both in individual projects and teams' projects.
For me, unlike git, fossil just gets out of the way and let's me focus on delivering. Doesn't have a whole bunch of arcane commands.
https://andreiclinciu.net/blog/why-im-using-fossil-scm-inste...
And from a quick bit of web searching, it looks like most IDE's out there either lack a plugin for fossil, or else have a plugin that's outdated and doesn't keep up with the current version of the IDE.
I realize that all of these "I Like X!" silly HN threads invite a lot of "I Like Y!" silly replies, but there sure are a lot of caveats on "better" here. You could make a much stronger case for recommending Subversion or CVS, lol.
edit: to clarify. It’s fine for a one man show or a small company. Once you get bigger, you start hitting the various issues quite often, and wish for github again.
Yes it is an open source project, but the entire team that works on it is based out in China, and that's really not something you want to play games with.
No offense to anyone and do not want to imply anything nefarious is about but from what I remember Gogs was even worse in that only a single maintainer inside P.R.C had merge access to the main branch. Also a concern because I might remember something about known vulnerabilities having been outstanding on the issue-tracker when the maintainer was busy.
For tools like this the aim is always to lay low and expand to reach as far as possible, then once you have a lot of control and trust you can abuse it, often you can abuse it without much loss, because once you have institutional momentum it's very hard to screw it up.
You can't operate on If there's a history of abuse of power, only if there is an incentive. I believe there's a very strong incentive in this case.
The fact that itself hosted is actually a really huge concern, because this thing is sitting on your local network with no firewall between it and everything else that you run.
It takes very little to put a vulnerability in a piece of code, and unless you have a person combing every commit with a fine tooth comb, even the fact that it's open source cannot prevent that.
No single security measure is bulletproof. Being open source does not counteract the misaligned incentives.
It looks like they got developers from bunch of other locations at least according to their Github activity.
But you are correct, they do get commits from outside of the country
Maybe you could expand on why this is an issue.
The fact that it's open source helps a little bit, but I do not believe they number of eyes on the project is enough that they couldn't sneak something through if they wanted to. This isn't Linux with worldwide attention, it's a relative niche.
Of course, we/I understand open source software isn’t perfect and such. That isn’t my point, I’m just saying that Gitea could use a complete rewrite, ideally using NextJS (if SSR is that important) or moving most if not all view logic into the client side, ditching go-macaron and xorm for something more widely used, relying less heavily on go templates, and doing error handling a bit better.
That said, Gitea does have a good excuse which is that it inherited many of these things from Gogs, from which it was forked.
> nonstandard web framework (go-macaron)...
The "standard" is React and Vercel offerings. Get with the times.
> ditching go-macaron and xorm for something more widely used...
You're only supposed to use libraries that are #1 popularity in their respective category, few weeks of no commits means the library is dead.
> I would also add that I don’t even like NextJS. I’m recommending it because it’s a better engineering choice...
Yes, you read that right. This is the advice for Gitea: Github, Gitlab, SourceHut all used server-side templates, so much so that latter two are quite useful even when JS is disabled- but the "better engineering choice" (citations sorely needed) is NextJS.
Xorm is so old and disused, it's been absorbed into Gitea and the Github repo is archived as read-only. You get much better capability out of something that's widely used, that's it. I don't care at all about how "modern" something is, if you can't roll back a migration because of your ORM then you have a nonideal ORM.
> The "standard" is React and Vercel offerings
No, I was thinking Gin or Buffalo. Something that a lot of people use and that's seeing a lot of love, you know... a standard.
> they can't simply accept when someone does things differently.
Yea, that's why I continue to accept Gitea as a good piece of software. Only people who cannot accept software packages as they are go out, call them "good", and try to get people to understand how it can become even better.
As for the so what, I think the answer is just that things can be better, so if someone is out there reading this thread who has some time, they can see this and know what kind of improvements can be made.
> If it ain't broke don't fix it? Or is there some specific shortcomming that might justify a rewrite?
I’m answering that question. The information is out there, so if people want to ignore it that’s beyond my mandate. But this is still constructive since someone out there wanting to rewrite Gitea will want to know what the pain points are before they do so.
(I really do want to know, I don't mean this question in any negative way.)
{{range $i, $file := .Diff.Files}}
<div>
{{ if $file.IsSpecialFile }}
<div>Special file ({{$file.name}})
{{ end }}
</div>
{{end}}
Then there are clerical things like where to put styles and presentation logic. Gitea uses a mix between jQuery and Vue, with CSS rules sprinkled in randomly. The result is that by looking at the template and the class names on each element, you have no idea whether a class name or ID is going to have significance to jQuery, CSS, or if it's just dead code. Something like styled-components, and use of a single stack (Next as opposed to jQuery+Vue) eliminates the fear and clerical aspect of development.
For migrations, if a migration fails, you have no way of rolling it back because they only go up and not down. This is just a specific instance of the problem of having less popular dependencies — the bug fixes and new features are less plentiful because there’s not as wide of a community. That applies to xorm and go-macaron.
Here's a good sample file. The cyclomatic complexity is through the roof: note the variable assignments, function calls, string concatenation, large number of `if`/`else if`s, nested conditional expressions (line 254). I don't even want to know how many permutations of this page are possible...