To make it clear: I wasn't talking about gitlab on-premise but about gitlab.com SaaS
1 Like
I wouln't say that these arguments are really convincing. Except fido support maybe. But anyway
1 Like
@aparcar Since you mentioned problems with Gitea, I'll express my opinion on GitLab.
Having maintained a few self-hosted GitLab instances, I can say that it's not hard. GitLab Omnibus installation makes installation and updating as simple as typing sudo apt install gitlab-ce. I had problem with updating only once, and that was only because I was trying to update from an old version without consulting the migration path. It supports pre-commit (and other) hooks that you said are missing in Gitea. Merge requests work like on GitHub. I didn't use Gitea so I can't comment on that.
I currently administer an instance in an enterprise environment with GitLab's own CI/CD runners. We don't have any issues with it, and their CI/CD system is good enough that we don't need to use a separate solution like Jenkins.
It also supports Google and GitHub login, so existing users wouldn't have to create new accounts for OpenWrt's self-hosted instance.
They do like to shuffle the UI every now and then, but it's mostly limited to admin panel and advanced functions like analytics, not something that everyday user interacts with. And yes, it feels bloated sometimes.
My point is, there's no reason do dismiss GitLab based on "administrative overhead" as it boils down to just installing Debian and updating one package (and two more, Runner and Docker, if they would be used, but that can be separated from the first host). It can handle renewal of Let's Encrypt's certificates, so even that part of administration is sorted out. In the "Microsoft bad, GitHub bad" narrative, it's odd to me that GitLab was so easily dismissed in favor of "bad" GitHub, and that some efforts of test migrations to GitLab were, as I recall, silently ignored.
I'm not endorsing GitLab, but right now it seems like the best full-featured free self-hosted solution that requires very little administrative effort. And it could probably be easily integrated/merged with existing Buildbot system which is already based on Docker. Or replace Buildbots which comes with the bonus of eliminating old/stale instances due to the way that GitLab's CI would be configured in my vision.
1 Like
@danijeltudek I don't know much about Gitlab, so please excuse my ignorance. Let us discuss in parallel 
With regard to Gitea:
-
@aparcar I found a pull request on Gitea that adds pre-receive hooks to check for email privacy, but i guess this is not the type of pre-commit hook feature you are referring to, right? Is there already an issue dealing with this, over there? In other words, are the gitea developers aware of the lack of pre-commit webhooks?
-
For a potential future decision to migrate from github to gitea: There is a large pull request in the making that deals with migration from github to gitea
I meant when it comes to big data. If you are using an Android phone, would you use Google Keyboard or Microsoft. And IF you had to choose, would you use Chrome or Edge?
everybody likes pizza with pineapple,
everybody have driver license,
everybody have
I'm sorry but you're wrong. Not everybody has the same thing as others. Be it gihub account, or even a driving license or a phone! This kind of assumption are really really bad.
It's very good move. Certainly, GitHub has a much larger, much wider reach among technical people. Tons of software are hosted using GitHub.
I have a question regarding the bug tracker migration.
For example, this issue was created at the old bug tracker, and apparently there are attached files, but it seems that the bot only copied the text.
Are the attached files no longer available? Or are they available at another location?