Already upgraded our gitlab RDS instance to PostgreSQL 11. AWS makes stuff like that very easy. We use the free version of gitlab and find it very capable. That plus Jenkins plus artifactory we have a nice little setup.
Yep. We were svn using “beanstalk” when I joined our company and pushed for a git migration. But we already had Jenkins running with tons of stuff set up on cloud bees. Then they kicked us off for some reason (forgot why) so it started our own migration to AWS
Integration errors are hard to chase in Gitlab (For example: Something went wrong while creating your Kubernetes cluster
Unexpected status; ROLLBACK_FAILED) - this does not give the user any information. Perhaps I could get some help here on this.
Familiarity mainly. We have a dual Jenkins setup (one internal one at our clients site) so we have a metric ton of Jenkins stuff from years and years of work. I can also write Jenkins pipelines in my sleep from doing it so often and have probably read about GitLab’s yaml format for a few hours. Maybe one day we think about getting rid of Jenkins but I am quite fond of it.
Github is great at one thing(so far): the UI never change. We did use Gitlab for sometime but the UI and slowness compared to Github was so noticeable. I wonder if its still the case now?
My current team/employer uses a self hosted Atlassian stack... I only use BB to find the repo URL before immediately cloning it. I can find my way around it relatively fine, but wow is it slow to load any kind of information. Not sure how much of that is the server it’s on or the application itself.
The UI on Github absolutely does change, about once a year they've done some small or even large changes to how Github looks and behaves. For me personally, I spend quite a bit of time looking for the right tab I want to navigate to and while I'm not lost, it takes along time to scan the UI and find what I'm looking for. I've preferd Gitlab's interface for the last few years over github simply because how much faster I can find everything.
One big thing gitlab has that github doesn't is the ability to download (or clone I think)repositories from a mobile browser without changing to desktop view. Yes there are actual reasons why someone would want to do this.
Maybe I'm blind, but I've scoured the mobile page for a download or clone link and always ended up giving up and switching to desktop view. I just checked again, and couldn't find them after a few minute search. On gitlab, it's immediately visible just above the clone repository link on the main repository page.
Yes, that explains their methodology but not the location of the hardware. If I go and run a Lighthouse audit on localhost vs. a server in Philadelphia there's going to be an inherent difference.
I remember reading that they also ran the benchmark in Germany and got similar results when first reading about this here on hn.
Anyway, it suffice to use gitlab, github, bitbucket and sourcehub for a few seconds to notice the slowness of the three first sites compared to the last one.
We didn't really need the numbers to be convinced but I hope they will produce some pressure to be faster.
Sorry, I seemed to remember they did something to make it fair, I don't recall the location. I use sr.ht and I've used the others and, for me, it feels like 'turbo mode' compared to them. Especially git pushing: it's faster than pushing to my dokku server that only I use!
Very true. I'm in a different part of the country (I'm in Boston, they're in Philadelphia) and tried running the benchmarks myself about a week ago. Unfortunately, I didn't save the results, but if you take my word for it, I remember getting similar results with only slightly different numbers. Your best bet, of course, is to run the benchmarks yourself: https://git.sr.ht/~sircmpwn/forgeperf
Some other people ran the benchmarks from different places in Europe and got similar results with "nothing significantly different" from those published: https://news.ycombinator.com/item?id=22900649
SourceHut is still the winner of most, but GitHub is a lot faster than in the report on forgeperf.org.
I think the perceived speediness of GitHub for me can be mostly attributed to the fact they don't trigger a full page reload for every navigation. Whereas SourceHut is rendered completely server-side AFAIK.
Thanks for sharing this. I'm part of the team within GitLab's Quality Engineering group that is tasked with performance testing GitLab. We've been working on vastly increasing our performance testing and visibility for about just under a year now.
I've been digging into these results today as a priority. While we're using different tooling (k6 and SiteSpeed respectively) and a different methodology (SourceHut is running tests with simulated low bandwidth) our tests are indeed generally showing the same pattern and I've confirmed we have issues raised to cover the problem areas.
Alongside this we identified a few gaps in our performance testing that we wanted to address immediately:
* Our File Blame page (and API) in particular was sobering to witness and we've added that into our tool's tests today (that you should be able to see in our results from tomorrow - https://gitlab.com/gitlab-org/quality/performance/-/wikis/Be...). We've raised 2 top priority issues for that area that will hopefully get tackled soon.
* Our file view page, with larger files, is also not as good as it should be. We've pivoted our tooling to test the worse case scenario today with a much larger file and raised an issue for it also for our dev teams.
As part of the company wide effort to improve our performance I'm always keen to see new tests being done or highlights of areas we haven't been able to cover yet so thanks again for highlighting this and hopefully you'll see our numbers continuing to improve soon!
Up until a couple years ago [1], the main tabs were in a collapsable sidebar on the right [2]. They just keep cramming more junk on the top, pushing the actual source code further below the fold, and making the header so wide it hides half its functionality inside a 'hamburger' unless you make the window super-wide.
The main GitHub.com page itself used to be clearly for developers, with "Search public git repositories" the very first item. Now it still says "for developers" but it's all about "GitHub Enterprise" and "Your business needs". Multi-repo search is actually disabled for non-logged-in users.
The style doesn't change, but the layout and functionality definitely does, and (IMHO) not for the better.
Can I request removing default CI/CD/AutoDevOps stuff from projects? Also, perhaps improve AWS EKS integration. Is there a place to get help on gitlab on chat? IRC seems to be pretty slow to get help.
> As we continue to work towards version control for Snippets, we are making a change to search for Snippets in the UI and API that removes snippet Content from search results. Title and Description will still be accessible via search and API.
This makes me a bit sad, but it probably has a valid technical reasoning. I just have to be a bit more descriptive in my descriptions I guess!
I'm excited to have version controlled snippets. I used to use Github Gists just for this feature.
Snippets work great for team collab as I can throw up a random snippet and iterate on it now with version control instead of copying or replacing it as the previous design forced me to do.
Yes, there's some reasoning behind the decision to remove snippet Content from search results. You can find the original discussion and decision in this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/199220
I find it very frustrating that Gitlab requires Javascript for simple basic things. You can't view replies to issues or even browse files in a repository. GitHub UX is so much better, but sadly many projects moved to Gitlab because of Microsoft acquiring GitHub.
> I find it very frustrating that Gitlab requires Javascript for simple basic things. You can't view replies to issues or even browse files in a repository. GitHub UX is so much better, but sadly many projects moved to Gitlab because of Microsoft acquiring GitHub.
How much coverage does the API have? In theory it should be 100% as the website uses (as far as I remember, haven't looked into the source) Vue.js but I'm not sure in practice. If the coverage is 100% or near 100%, you should be able to do many of the things in the terminal or it is possible to have a completely server-side web application (not sure of the exact terminology, I mean like the delightful SourceHut[0] thing). The biggest concern is ongoing maintenance as Gitlab tends to move pretty quickly.
> I don't really see the point. GitHub has only improved since they were acquired.
Fully agree, but apparently some projects don't like having their infrastructure owned by Micosoft, that would be the only reason for switching in this case.
GitLab 13.0 will release on the 22nd of May, 12 days from now. This blog post is about the upcoming deprecations in that release, not the features. The features that might ship in that release are on https://about.gitlab.com/upcoming-releases/
> An offset-based pagination limit of 50,000 is being applied to the /projects API endpoint on GitLab.com.
This feels familiar. I once designed an API for retrieving a large number of items (hundreds of thousands to millions) from a Postgres database. I quickly learned that using OFFSET for such queries is an anti-pattern because it forces Postgres to iterate through all items before the specified offset just to retrieve the few items you requested. So allowing unlimited offsets is a great way to grind your database to a halt.
I learned that a better way to do this is to use an index-based query instead, which Postgres can deal with much better. For example, you could give your items an auto-incrementing sequence number and tell the API consumer the sequence number of the last item in the result set. For the next request the consumer can use this number to start off where it left. While that restricts the way you can order items it will greatly speed up queries and allow efficient retrieval of a very large number of items without running into the slowdown effect caused by offset-based pagination.
In the real world such indexing methods aren’t practical, once you have to do a full text search for example or sort by some attribute the index becomes useless. It’s rare to only want results presented in a certain order IMO.
I recently hit a reCAPTCHA while trying to edit a ticket on one of my projects hosted on Gitlab.com. Since I block reCAPTCHA, this was silently failing and I had to debug this. This prevented me to edit this ticket. This is bad.
I initially chose Gitorious when I needed to share an open source project because it was free software. I've been transfered to Gitlab.com and was ok with this back then.
But requiring me to run this piece of non free tracking malware and solve a captcha to manage my free software project, and worse, making me force this upon the contributors of my projects? This is bullshit.
I know the Gitlab staff is on HN, so thank you for your amazing software and for the free hosting, but be aware that this is making me move as soon as possible and actively discourage people from using Gitlab.com. ReCAPTCHA is not OK. Never.
Developer Evangelist at GitLab here. Sorry that you had a hard time debugging the failure. I had gotten these reCaptcha questions myself recently. In the past months, there were numerous spam waves with flooding the issue tracker. You can see that with the increasingly high issue number, as their IDs have been burnt.
I agree that reCaptcha is not the best solution. We have an ongoing discussion which also includes replacing reCaptcha with hCaptcha. While I cannot make a promise, I recommend that you subscribe to the issue. Also, please add your thoughts in there too :)
Next to having captchas, there are other spam prevention ideas. One of them would be to follow a trust level model such as Discourse, but that needs more long-term planning and a fair model to let existing users becoming trusted.
as an admin and a user, im totally happy with gitlab. its a easy enough to administer, its reasonably priced even for a small company, and they dont try to push their "cloud offerings".
58 comments
[ 4.5 ms ] story [ 104 ms ] threadEdit: I realize it might be more suitable for data pipelines than continuous integration.
https://www.youtube.com/watch?v=cHATHSB_450
https://www.youtube.com/watch?v=6eNiCLanXJY
EDIT: typo closing -> cloning it.
Maybe I'm blind, but I've scoured the mobile page for a download or clone link and always ended up giving up and switching to desktop view. I just checked again, and couldn't find them after a few minute search. On gitlab, it's immediately visible just above the clone repository link on the main repository page.
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37624
https://imgur.com/0yg4Mfc
1. SourceHut
2. Codeberg
3. GitHub
4. Pagure
5. GitLab
6. Bitbucket
Source: https://forgeperf.org/
Edit: see "Expand for details on methodology" right at the top of the page.
Anyway, it suffice to use gitlab, github, bitbucket and sourcehub for a few seconds to notice the slowness of the three first sites compared to the last one.
We didn't really need the numbers to be convinced but I hope they will produce some pressure to be faster.
Some other people ran the benchmarks from different places in Europe and got similar results with "nothing significantly different" from those published: https://news.ycombinator.com/item?id=22900649
SourceHut is still the winner of most, but GitHub is a lot faster than in the report on forgeperf.org.
I think the perceived speediness of GitHub for me can be mostly attributed to the fact they don't trigger a full page reload for every navigation. Whereas SourceHut is rendered completely server-side AFAIK.
(I meant GitHub in my previous comment, fyi.)
We know there's work to be done with GitLab's performance and it's a top priority for us moving forward. We've blogged recently on our (Quality) efforts here - https://about.gitlab.com/blog/2020/02/18/how-were-building-u... and you can also see all the issues we've got here - https://gitlab.com/gitlab-org/gitlab/-/issues?label_name[]=Q....
I've been digging into these results today as a priority. While we're using different tooling (k6 and SiteSpeed respectively) and a different methodology (SourceHut is running tests with simulated low bandwidth) our tests are indeed generally showing the same pattern and I've confirmed we have issues raised to cover the problem areas.
Alongside this we identified a few gaps in our performance testing that we wanted to address immediately:
* Our File Blame page (and API) in particular was sobering to witness and we've added that into our tool's tests today (that you should be able to see in our results from tomorrow - https://gitlab.com/gitlab-org/quality/performance/-/wikis/Be...). We've raised 2 top priority issues for that area that will hopefully get tackled soon.
* Our file view page, with larger files, is also not as good as it should be. We've pivoted our tooling to test the worse case scenario today with a much larger file and raised an issue for it also for our dev teams.
As part of the company wide effort to improve our performance I'm always keen to see new tests being done or highlights of areas we haven't been able to cover yet so thanks again for highlighting this and hopefully you'll see our numbers continuing to improve soon!
Up until a couple years ago [1], the main tabs were in a collapsable sidebar on the right [2]. They just keep cramming more junk on the top, pushing the actual source code further below the fold, and making the header so wide it hides half its functionality inside a 'hamburger' unless you make the window super-wide.
The main GitHub.com page itself used to be clearly for developers, with "Search public git repositories" the very first item. Now it still says "for developers" but it's all about "GitHub Enterprise" and "Your business needs". Multi-repo search is actually disabled for non-logged-in users.
The style doesn't change, but the layout and functionality definitely does, and (IMHO) not for the better.
[1]: https://github.blog/2015-11-16-a-new-look-for-repositories/ [2]: https://visualstudiomagazine.com/articles/2015/03/23/~/media...
Github's never changing ui was also partly because they didn't have half the features gitlab does for a long time.
Gitlab is quite complicated to look at, it could be improved. But it's also partly because it is getting quite complicated.
This makes me a bit sad, but it probably has a valid technical reasoning. I just have to be a bit more descriptive in my descriptions I guess!
Snippets work great for team collab as I can throw up a random snippet and iterate on it now with version control instead of copying or replacing it as the previous design forced me to do.
[1] https://sourcehut.org/
How much coverage does the API have? In theory it should be 100% as the website uses (as far as I remember, haven't looked into the source) Vue.js but I'm not sure in practice. If the coverage is 100% or near 100%, you should be able to do many of the things in the terminal or it is possible to have a completely server-side web application (not sure of the exact terminology, I mean like the delightful SourceHut[0] thing). The biggest concern is ongoing maintenance as Gitlab tends to move pretty quickly.
[0] https://sourcehut.org/
I don't really see the point. GitHub has only improved since they were acquired.
Fully agree, but apparently some projects don't like having their infrastructure owned by Micosoft, that would be the only reason for switching in this case.
The last GitLab release was 12.10 which was release on April 22 https://about.gitlab.com/releases/2020/04/22/gitlab-12-10-re... with Requirements Management and Autoscaling CI on AWS Fargate
https://www.youtube.com/playlist?list=PL05JrBw4t0KqWysAAKFYY...
This feels familiar. I once designed an API for retrieving a large number of items (hundreds of thousands to millions) from a Postgres database. I quickly learned that using OFFSET for such queries is an anti-pattern because it forces Postgres to iterate through all items before the specified offset just to retrieve the few items you requested. So allowing unlimited offsets is a great way to grind your database to a halt.
I learned that a better way to do this is to use an index-based query instead, which Postgres can deal with much better. For example, you could give your items an auto-incrementing sequence number and tell the API consumer the sequence number of the last item in the result set. For the next request the consumer can use this number to start off where it left. While that restricts the way you can order items it will greatly speed up queries and allow efficient retrieval of a very large number of items without running into the slowdown effect caused by offset-based pagination.
I initially chose Gitorious when I needed to share an open source project because it was free software. I've been transfered to Gitlab.com and was ok with this back then.
But requiring me to run this piece of non free tracking malware and solve a captcha to manage my free software project, and worse, making me force this upon the contributors of my projects? This is bullshit.
I know the Gitlab staff is on HN, so thank you for your amazing software and for the free hosting, but be aware that this is making me move as soon as possible and actively discourage people from using Gitlab.com. ReCAPTCHA is not OK. Never.
Cloudflare made the move [1]. Will you?
[1] https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptch...
Developer Evangelist at GitLab here. Sorry that you had a hard time debugging the failure. I had gotten these reCaptcha questions myself recently. In the past months, there were numerous spam waves with flooding the issue tracker. You can see that with the increasingly high issue number, as their IDs have been burnt.
I agree that reCaptcha is not the best solution. We have an ongoing discussion which also includes replacing reCaptcha with hCaptcha. While I cannot make a promise, I recommend that you subscribe to the issue. Also, please add your thoughts in there too :)
https://gitlab.com/gitlab-org/gitlab/-/issues/21998#note_325...
Next to having captchas, there are other spam prevention ideas. One of them would be to follow a trust level model such as Discourse, but that needs more long-term planning and a fair model to let existing users becoming trusted.
Please see https://gitlab.com/gitlab-org/gitlab/-/issues/14156#note_258... for more details.
Cheers, Michael
I which good luck to the GitLab team against spam.