💾 Archived View for blog.schmidhuberj.de › 2022 › 04 › 13 › what-to-think-of-gitlab captured on 2024-05-12 at 15:10:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Posted on 2022-04-13
I must honestly say, I do not know what to think of GitLab. The university has several self-hosted GitLab instances that I really enjoyed using. I have therefore started using the main gitlab.com instance in my free time, but I do not really enjoy using this.
Before every login attempt, GitLab (or probably CloudFlare) wants to check my browser, for some reason. I have both allowed cookies and JavaScript for GitLab, so I see no reason for them to do. And I mainly see no reason for this check to take 10 seconds. I really wonder what the servers are doing during this time.
The CI is probably one of the best things with GitLab which I also really enjoyed using on the self-hosted instances. I therefore looked forward to using CIs on my private repositories. But before running CI, GitLab wants to verify my identify by giving them my credit card information. The CI is still free to use, but I really do not like giving them my credit card information as I believe such information should stay always-offline (or rarely-only in some and well-though-through cases). I could also self-host a runner, which I also did on the universities GitLab on a university server. But this would also make the CI not-free as I currently do not have a suitable server for that. Well, I guess I have to live without CI for now.
You know these "Unknown sign in from new locations" many websites send? In theory, they are definitely not bad, but when using GitLab with a browser that deletes cookies automatically after closing, I get this message daily. GitHub, as far as I remember, had the same problem, but when adding a security key they do not send this mail any more. With GitLab on the other hand, there is no way to opt out of these mails.
As a workaround I just made a mail filter that marks these mails as automatically read and moves these to a folder for that. Suboptimal, but acceptable. There are of course issues open for this, both on administrative side and on user side, but there is no progress. There issues also lead nicely to the next point.
If you have taken a look at above linked issues, you will notice that the issue for the administrators has been closed, but the issue for the users is still open (last checked: 2022-04-13). Both were opened at approximately the same time, about one year ago. And the issue for the administrators took only a little bit over one month to be closed.
The reason for that is immediately clear when looking at the comments of the first issue. Every second comment is something like "Big Fish opened a ticket about this" (where "Big Fish" is some company paying GitLab for their services). From a business perspective, this is obviously the most profitable, but also not nice for normal users.
Yesterday I wanted to integrate GitLab into mastersearch. But I figured out that the search was pretty much unusable, only returning some matching results. This is because only projects from paid accounts are indexed, which pretty much removes the majority of projects from the search. Therefore, I find GitLab search pretty much unusable and not worth the time integrating into mastersearch. There is also a issue open for that, lets see when this will be fixed.
I really enjoyed using GitLab on a self-hosted instance, but there seem to be so many minor and major annoyances in the main GitLab instance that I do not know weather I should use it further. Lets look at my next options:
Looking back at it, I saw that I do not really need their services actively. Like previously mentioned, I will be notified if something happens. I think that is therefore sensible (for now) to just stay on GitLab, but not interact with it if not needed.