We try to make a little bit of progress on many features each month. So most of the time we won't have any giant new features, progress happens iteratively. You might also notice lots of deprecations as we get closer to 14.0 (immediately after 13.11) Happy to answer any questions.
Hi Operyl - GitLab Product Leader here. Our process for updating the What's New content is delayed slightly from the release (as we use the release post images that are published on the 22nd for the What's New highlights). They'll show up shortly.
This seems really bizarre to not be included with the .0 release. The features are live, but the label states "Your instance (current version) is 13.9". It could do with some more refining perhaps.
Hi Operyl, GitLab PM here. Thanks for the feedback on What's New. As you point out, it looks like we have some opportunity for refinement and better/clearer messaging for folks that update right away to the .0 release. I've opened up this issue to track that work and welcome your feedback or ideas there. Thank you! https://gitlab.com/gitlab-org/gitlab/-/issues/325591
I like Gitlab's OSS philosophy and documentation (including these lengthy release notes) a lot.
If there's one feature I really miss in Gitlab than the limited issue trackers. Despite Jira is still the "go-to" solution in many companies, I feel that many try to avoid that monster of a software, especially since Atlassian no more offers a self-hosted variant. I'd love to see more things like GANTT charts included (there is only a Kanban board display for issues, not yet some Waterfall or agile/GANTT board).
An issue for us is that we need to provide outside users access to support tickets. Gitlab has Service Desk, but it's useful only if it's just your engineering team looking at the issues. Service Desk issues often need attention from someone outside the engineering team, though.
There's a steep step-up from Premium (which we are at) to Ultimate to get guest accounts, but even with guest accounts, we'd need to separate access of service desk tickets from internal tickets.
Jep, I've also noticed many shortcomings from the gitlab service desk feature. For us the problem was that when replying users by email, they could not open attached files without an account on our installation.
Redmine has these features since a long time, and I think it's worth for Github to catch up...
> Free is for a single developer, with the purchasing decision led by that same person
> Premium is for team (s) usage, with the purchasing decision led by one or more Directors
Doesn't this conflict with the stewardship promise that "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories"?
I really like how GitLab is shaping up. I hope they start getting a bit more mind share from GitHub, but I think they really shot themselves in the foot with that recent pricing change. [1]
Having to pay the same amount per license, for folks that just want to create/edit or even just view issues, as a full blown developer is simply not tractable. There's a lot of value in the platform and all else equal I'd probably pick GitLab if I had to choose between GitLab, GitHub, BitBucket, JetBrains Space, or Shudder Azure DevOps.
But the price. Damn, it's just impossible to make that argument to yourself, never mind your CTO.
yeah, my company aswell, we only need 1 required reviewer, but paying for that like $19 per user (we are 5, so $95 for that per month) is a little bit ridiculous. granted it probably comes with support, but as a small company you do not care about support, you care about $1200 a year. I loved the jira/stash pricing, 10 person shop was $10 a year so $30 with stash + jira agile (there was a time where agile costed extra), but no support. the price of course was ridiculously cheap, but granted that was something were you did not even needed to talk about the cost, it was assumed that it was worth it and there was no cost/feature evalulation.
edit: kudos to them they already offer tons of stuff for free.
I am curious, at what point will the features stop? Do we keep adding features until Gitlab becomes impossibly complex to use or onboard anyone? Why isn't Gitlab built like a modular app - add what you want but core should be simple as possible and feature complete. I am afraid but this is how a lot of applications die. Gitlab is starting to get bulky and obese already.
I feel like it's already .. kind of there. There are so many features that I'm lost in them, and some of them feel like they've been abandoned already.
Yeah, I was an avid user of self hosted gitlab previously, but the pace of added bloat^Wfeatures was just too much and I ditched it for gitea about 1 year ago.
I feel gitlab's is now mainly aiming at large enough companies which actually use all of these features.
Not sure why you feel that added features result in "bloat". We've been on Gitlab for 4 years now, and our core workflow not only hasn't changed, but also has not been impacted by any of the new features. On the other hand, we've expanded our usage beyond it, and it's always nice to need a feature and find out that it is right there under a menu and just needs some configuration to get it to work.
With them dropping the lowest license tier, you better start using all the features...
We have been Enterprise users since 2015, but are evaluating our options.
Just take a look at the gitlab ci reference. It is huge. And there are competing features in there that are intended to "deprecate" the older feature but this doesn't happen. They are also constantly held back on providing backwards support. For instance, adding dpeendency-like flow as opposed to stage based flow has been added but it's not possible to model dependencies from same stage making the whole thing kind of useless.
Versioning the yaml specs/apis is the correct move.
I hope future CI systems take note.
Seems trivial to add a version field to the root object if they ever go down that route.
I haven't had any older yamls break and I wouldn't say the yaml schema is worse off because of backwards compatibility. Not sure a version would change much atm.
Eh.. I think the comments here are telling otherwise. I'll admit I haven't used Gitlab in over a year now. But I know the entire team I worked with really despised the switch to Gitlab internally. So much so we dragged our feet as the only team staying on Github while the rest of the company moved to Gitlab as long as we could.
It was a really unpleasant experience using Gitlab. The diffing in particular was truly awful by comparison. And in general everything was slower with Gitlab.
You should rethink this mindset of doing both at the same time and focus more on making what you have now better. It would likely benefit you greatly.
I’m curious what are some products that successfully do this? I honestly can’t think of any at the top of my head.
To me, more features and ease of usability can’t coexist. There must be compromises. I’ve heard the argument that it’s possible by hiding the advanced features, and I would agree in the short term. But internally, as teams grow and have to maintain multiple documentations noting depreciations, it creeps on the user’s end. It becomes harder to read documentation and there’s also the burden of trying to understand what it’s for because it was something that replaced a previous feature which I don’t have context for.
Please add features responsibly, and stop rewarding new features that seem helpful in a handful of use cases. But who am I kidding here
I'm inspired by products like Zoom, Chrome, VScode, and Slack that are both user friendly and full featured.
Any examples of features that we probably shouldn't have added and should consider removing?
We intent to replace the DIY DevOps toolchain with GitLab. Something that consists of many applications and interfaces. Just having it in a single application would already be a big quality of life improvement for the users. And so far the most common hurdle is being able to match the functionality of the point solutions.
I think this is a real strategic challenge for Gitlab; I think the answer is "the features never stop", and that is OK, as long as you understand their target customer/market.
I first started thinking hard about this when they recently cancelled their bronze tier subscription. Gitlab is clearly ducking out of a brawl with Github for the individual/consumer $5/month tier; that makes sense as there is no way Gitlab can win by taking on the incumbent on their own turf. Instead Gitlab seems to be shifting focus to targeting larger enterprise customers; those who are fine paying $20/mo or ideally $100/mo for a one-stop solution to the full SDLC. (The counterargument here would be that they _are_ still targeting the $5/mo customer, they are just trying to replace a $5/mo Github subscription plus a $10/mo CircleCI sub plus a $10/mo Jira sub etc. -- I'm not sure I see that end of the userbase being as amenable to bundling though).
The largest enterprise customers will keep asking for more boxes to be ticked, because it's usually easier to add features onto your existing solution than to stitch multiple solutions together, and because the more features/config options you have, the more complex configurations/requirements you can satisfy. However that means you get feature bloat, and pricing becomes more challenging; you need to charge more for "all the features" tier, but as you broaden the offering, fewer customers actually want to pay for everything. "What do we keep in the $100/mo tier?" is a challenging question to get right as the feature-set grows.
As you get into enterprise sales, you start to need more customization/unbundling. Before I moved back to Github I paid Gitlab $20/mo per engineer on my team and would never dream of jumping up to $100/mo, but would absolutely have paid more for a la carte access to certain features from the $100/mo ultimate tier. (For example I have no interest in their issue tracker, but I'd love to have been able to use their DevOps / Kubernetes tooling).
I believe this sort of a la carte pricing is less developer-friendly because you tend to need to talk to a sales person vs. just having the developer sign up, but then I don't believe that "developer first" is your sales strategy in enterprise; see Okta vs. Auth0 for a good example:
Auth0 keeps it as simple as possible. Even within customer-identity (their competitor to Auth0) Okta has way more configuration for add-ons like MFA, SSO etc.
(I know @sytse / Gitlab folks post on here regularly so I'd love to hear their feedback on whether I'm completely off-base in how I'm thinking about this stuff!)
Thanks for inviting me to comment. I think we still cater to individual contributors with our Free offering.
It isn't so much about the customer but about the product. Our ambition went from being a source code tool to a complete DevOps platform delivered as a single application.
I think a lot of the changes you see can be explained from that.
If anyone from Gitlab happens to read this, how is ActionCable working out for you on gitlab.com? If you're not from Gitlab but use ActionCable at moderate scale feel free to share your story too!
I casually read a few PRs and issues from a year ago where you discussed introducing ActionCable but it looks like a full blown report hasn't been written up on how it panned out, but I do see it being referenced in your HTML.
Concerns were mainly around memory usage, such as it growing to pretty huge sizes even with idle connections. I know there were lots of horror stories of major memory usage early on. The memory growth climbed very quickly with active connections, but I wonder now with Rails 6.1+ if those issues have been ironed out.
Last thing I heard we're no longer worried about memory usage. We where thinking about using AnyCable to address memory concerns but that is off the table at the moment because it isn't an issue anymore.
Are you no longer concerned because memory usage dropped significantly?
How's the overall latency?
I remember seeing some benchmarks where ActionCable was using like 1-2gb of memory for around a thousand active connections with 95% percentile latency in the multi-second range to broadcast a message. I do see AnyCable makes huge improvements here and I love the idea of it but also not too sure how backwards compatible it is with Hotwire / Turbo Streams.
I've always thought Rails was good / fast enough but the ActionCable stuff worries me a little because a single low end VPS could happily handle a very solid amount of traffic (tens of thousands of daily page views, etc.) but once you start factoring in websocket connections that changes everything. Suddenly pages that have completed the request / response cycle are still on the hook to keep a ws connection open even if they're not doing anything that causes a state change.
I feel that Gitlab needs to optimize for the 90% use case instead of adding more features.
For example does anyone else find Gitlabs diff lacking? It makes reviewing large patches painful, with the seemingly constant fetching of individual file diffs and inability to show large file diffs. The UI in general feels sluggish, especially when compared to something like Gerrit or GitHub.
So much second this. It actually feels like it is getting slower on each upgrade, and more buggy. Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh? Given that I spend most of my time on GitLab reviewing, this is a real pain point for me.
> Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh?
I don't think I've seen that reported before and we have been working through some interesting to reproduce issues in recent milestones.
Would you mind opening an issue for this? Feel free to tag me (same name).
There's an open issue for one thing I notice all the time: the next/previous unresolved commands update some internal state but scrolling and other navigation do not. This means that if you use any other navigation mechanism (e.g. search) the next time you hit “go to next unresolved” button it will instead scroll backwards to whatever thread follows the last one you navigated to using the “go to next unresolved” mechanism even if that's scrolling hundreds of lines back.
The thing I miss the most from the reviewing process is the ability to review diffs per-commit.
This is closer to how git is used in the linux mailing lists but gitlab completely breaks that workflow. Github has added some support for that. And yeah, performance sucks, even for trivial patches.
Hi! I'm not sure if you've seen this, but in GitLab 13.0 we released commit based navigation for merge requests. You can read more about this in our docs, but we'd love any feedback you have on the feature.
I'm really noticing the performance on moderate-size code reviews — once you're over a few hundred lines changing their Vue.js code devolves into a JavaScript benchmark doing whatever it does before updating the DOM.
Hi, I'm André, the Frontend Eng Manager at GitLab for Code Review.
Thanks for that comment. As you can expect, we notice it too. This is something the team is actively monitoring and working to improve (example: https://gitlab.com/gitlab-org/gitlab/-/issues/321691 being worked on in the current milestone).
I am curious: have you tried the file-by-file mode? Some users have given us very positive feedback on this feature, others not so much. It might be something that fits some users' habits but not others. But thought it was worth mentioning. We're actually considering and researching turning this on automatically for MRs over a certain size (https://gitlab.com/gitlab-org/gitlab/-/issues/212849 your thoughts would be very appreciated there, thanks!).
https://docs.gitlab.com/ee/user/project/merge_requests/revie...
Not that it solves the root of the problem (that's being addressed too) yet this feature allows for really large MRs to be reviewed without having to render all the changes at once.
Hi! Thanks for the feedback on diffs - it's something we're always thinking about and working on in the group.
One of the things we're currently working on is putting monitoring in pace for all the of the diff limits - https://gitlab.com/gitlab-org/gitlab/-/issues/31063. The goal here is that we can further fine tune some of the limits in place to continue to help with larger merge requests.
The group also spent some time investigating ways to improve the blocking time for large merge requests and you can see some of the discussion around that here: https://gitlab.com/gitlab-org/gitlab/-/issues/295237.
Docker runner performance is horrible.
By using ssh runner which runs exactly the same docker command I save 7 seconds each time.
Thid leeds to many hacks to get performance needed (jobs are merged in one big one for example). With many smaller jobs some pipelines run sometimes up to 50% slower than ssh + docker.
Also built-in caching is painfully slow. Our self hosted minio instance as custom cache is 10 times faster than Gitlab's local cache and this is absurd.
These are 2 main speed issues with me.
As code reviewer large diff bad performance would be the 3rd issue. It lags even with my beefy workstation. Maybe adding JS functionality is needed for files in current viewport? I don't need syntax highlight and comments options on all 100 files at the same time but I want an option to scroll down and this functionality on currently viewed files
I'm so excited for this too! I'm really excited to continue bringing GitLab workflows closer to where developers are doing their work and hope this is going to be a really meaningful step in that direction.
I'm also interested to see what kind of impact it has on large MRs, but do know it's not the answer for what happens in GitLab.
Agreed. Diffs and MRs in general are terrible. We get 500 errors constantly when submitting MRs, if we can push up at all. And don't try to rebase with the button - OH MY it will just fail. Or it will succeed and the interface will not update. Yuck.
We are switching to GitHub. Which saddens me because I much prefer GitLab's interface. But I have lost the battle, due to GitLab's terrible performance.
Can we just get a decent unified Notification Center, please? Notifications in GitLab are painful, just copy how GitHub does it and stop trying to make it so complicated.
Not being a gitlab user I'm surprised its notification are worse than github's, because it's not like github's notifications are any good. Between the comment notifications which don't link you anywhere half the time (possibly on inline comments? I never remember) and the update notifications which give you a completely empty diff on a push force, it only serves to signal that something happened on this thing you don't even care about.
All GitLab notifications are via email unless someone explicitly @s you. Furthermore, there is no api to notification. Basically, unless you monitor email, you don’t get notifications. It’s horrible.
The Gitlab licensing model was recently change and the lowest tier starter license was removed.
Anyone knows which of these new features a customer receives that is still on "starter" (which can be kept for up to one year after the change to the license model)?
All new features target Free/Premium/Ultimate. Starter customer are still getting new features, improvements and fixes — they are the same features that are also available on the Free tier. For Starter customers who elected to upgrade to Premium for free, they will also have access to the new Premium features.
From my perspective, Gitlab needs to urgently reallocate 90% of its developper force from "Adding new features in 10 different axes" to "Stop adding new features and exclusively work on performance and consistent unified UX".
I know it hurts, I know it's probably not what devs at Gitlab aspire to, but I believe it is much needed. Possibly, an entire rewrite of some core aspects are needed. I have a lot of trouble selling Gitlab to my team. Everyone just wants to move to Github to have a simple UX that works.
Their best shot at competing with GitHub is on features ( and they do a pretty good job at it too), so i think they can't afford to stop shipping new features.
GitHub's UX is simple because it doesn't even come close to what GitLab provides, even in the free tier, and their iteration is much slower. If GitHub had GitLab's features it'd have a complex in some places UX as well.
They have no clue how to fix performance issues. These performance issue have been there for multiple years and users have been asking them to fix these. Instead, their core competency seems to be hire people to advertize and post "thank you" and "we are here to address your issues" kind of messages here at HN. They have a whole army of those users here (you can check past HN threads related to gitlab).
The feature releases don’t show up in GitLab’s RSS now... why not? Can’t find any way to subscribe to them.
13.9 didn’t appear and I had to go looking. 13.10 hasn’t either. Blog “news” posts, unfiltered and patch releases all show up in RSS... why aren’t the monthly releases being included anymore?
I was subscribed to https://www.gitlab.com/atom.xml - at least, that's what Feedly's UI shows, but that URL doesn't seem to resolve at all. In my Feedly, the newest article was "building a better Heroku".
When you search for GitLab in Feedly, you also see that feed, without the 13.10 post. The "GitLab" source at top of search results shows "about.gitlab.com", 6k followers, but no 13.10 post.
I've directly added your atom.xml link so my situation is resolved for now. Thanks!
I use GitLab at work and sourcehut for personal projects. And as much as I like minimalism, I have to admit how /nice/ GitLab is in comparison. But some complaints since some GitLab employees are watching:
- Syntax highlighting (for Python at least) is wonky.
- Changing profile pictures can take hours or days to propagate. Seems like a silly request, but I like changing my profile pic quickly.
- Metarepos (git repos using lots of submodules) are a mess in git and gitlab doesn't make it easier. It's either monorepo or manyrepo with no support for us inbetweeners.
- Frontend perf is snappier than some competitors, but not snappy /enough/.
- The search UI is bad. The widgets get in my way 90% of the time. And its slow.
How is the process going with reducing Javascript on the frontend? Simple things like reading replies to issues or merge requests should not require Javascript, it also makes Gitlab feel annoyingly sluggish compared to GitHub.
87 comments
[ 2.9 ms ] story [ 65.2 ms ] threadEDIT: That is, the one under the help tab in a Gitlab instance on the top right.
Maybe you're working on a self-managed version that still needs to be updated?
My instance is definitely updated, I did it myself and verified the version number in the Admin section.
https://about.gitlab.com/handbook/marketing/blog/release-pos...
If there's one feature I really miss in Gitlab than the limited issue trackers. Despite Jira is still the "go-to" solution in many companies, I feel that many try to avoid that monster of a software, especially since Atlassian no more offers a self-hosted variant. I'd love to see more things like GANTT charts included (there is only a Kanban board display for issues, not yet some Waterfall or agile/GANTT board).
There's a steep step-up from Premium (which we are at) to Ultimate to get guest accounts, but even with guest accounts, we'd need to separate access of service desk tickets from internal tickets.
Redmine has these features since a long time, and I think it's worth for Github to catch up...
https://about.gitlab.com/handbook/ceo/pricing/#buyer-based-t...
> Premium is for team (s) usage, with the purchasing decision led by one or more Directors
Doesn't this conflict with the stewardship promise that "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories"?
Thanks again for the question.
Edit - I've created an MR to document this on our pricing model page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
https://docs.gitlab.com/ee/user/group/roadmap/
Having to pay the same amount per license, for folks that just want to create/edit or even just view issues, as a full blown developer is simply not tractable. There's a lot of value in the platform and all else equal I'd probably pick GitLab if I had to choose between GitLab, GitHub, BitBucket, JetBrains Space, or Shudder Azure DevOps.
But the price. Damn, it's just impossible to make that argument to yourself, never mind your CTO.
1: https://news.ycombinator.com/item?id=25918717
https://gitlab.com/gitlab-org/gitlab/-/issues/213185
The more feedback they get the better.
edit: kudos to them they already offer tons of stuff for free.
I feel gitlab's is now mainly aiming at large enough companies which actually use all of these features.
Versioning the yaml specs/apis is the correct move. I hope future CI systems take note.
I haven't had any older yamls break and I wouldn't say the yaml schema is worse off because of backwards compatibility. Not sure a version would change much atm.
Regarding user interface modularity you can already turn on and off many parts in the front end https://imgur.com/a/aIRkDmt
Eh.. I think the comments here are telling otherwise. I'll admit I haven't used Gitlab in over a year now. But I know the entire team I worked with really despised the switch to Gitlab internally. So much so we dragged our feet as the only team staying on Github while the rest of the company moved to Gitlab as long as we could.
It was a really unpleasant experience using Gitlab. The diffing in particular was truly awful by comparison. And in general everything was slower with Gitlab.
You should rethink this mindset of doing both at the same time and focus more on making what you have now better. It would likely benefit you greatly.
To me, more features and ease of usability can’t coexist. There must be compromises. I’ve heard the argument that it’s possible by hiding the advanced features, and I would agree in the short term. But internally, as teams grow and have to maintain multiple documentations noting depreciations, it creeps on the user’s end. It becomes harder to read documentation and there’s also the burden of trying to understand what it’s for because it was something that replaced a previous feature which I don’t have context for.
Please add features responsibly, and stop rewarding new features that seem helpful in a handful of use cases. But who am I kidding here
Any examples of features that we probably shouldn't have added and should consider removing?
We intent to replace the DIY DevOps toolchain with GitLab. Something that consists of many applications and interfaces. Just having it in a single application would already be a big quality of life improvement for the users. And so far the most common hurdle is being able to match the functionality of the point solutions.
I first started thinking hard about this when they recently cancelled their bronze tier subscription. Gitlab is clearly ducking out of a brawl with Github for the individual/consumer $5/month tier; that makes sense as there is no way Gitlab can win by taking on the incumbent on their own turf. Instead Gitlab seems to be shifting focus to targeting larger enterprise customers; those who are fine paying $20/mo or ideally $100/mo for a one-stop solution to the full SDLC. (The counterargument here would be that they _are_ still targeting the $5/mo customer, they are just trying to replace a $5/mo Github subscription plus a $10/mo CircleCI sub plus a $10/mo Jira sub etc. -- I'm not sure I see that end of the userbase being as amenable to bundling though).
The largest enterprise customers will keep asking for more boxes to be ticked, because it's usually easier to add features onto your existing solution than to stitch multiple solutions together, and because the more features/config options you have, the more complex configurations/requirements you can satisfy. However that means you get feature bloat, and pricing becomes more challenging; you need to charge more for "all the features" tier, but as you broaden the offering, fewer customers actually want to pay for everything. "What do we keep in the $100/mo tier?" is a challenging question to get right as the feature-set grows.
As you get into enterprise sales, you start to need more customization/unbundling. Before I moved back to Github I paid Gitlab $20/mo per engineer on my team and would never dream of jumping up to $100/mo, but would absolutely have paid more for a la carte access to certain features from the $100/mo ultimate tier. (For example I have no interest in their issue tracker, but I'd love to have been able to use their DevOps / Kubernetes tooling).
I believe this sort of a la carte pricing is less developer-friendly because you tend to need to talk to a sales person vs. just having the developer sign up, but then I don't believe that "developer first" is your sales strategy in enterprise; see Okta vs. Auth0 for a good example:
https://auth0.com/pricing/ https://www.okta.com/pricing/#customer-identity-products
Auth0 keeps it as simple as possible. Even within customer-identity (their competitor to Auth0) Okta has way more configuration for add-ons like MFA, SSO etc.
(I know @sytse / Gitlab folks post on here regularly so I'd love to hear their feedback on whether I'm completely off-base in how I'm thinking about this stuff!)
It isn't so much about the customer but about the product. Our ambition went from being a source code tool to a complete DevOps platform delivered as a single application.
I think a lot of the changes you see can be explained from that.
Zawinski's Law:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
I casually read a few PRs and issues from a year ago where you discussed introducing ActionCable but it looks like a full blown report hasn't been written up on how it panned out, but I do see it being referenced in your HTML.
Concerns were mainly around memory usage, such as it growing to pretty huge sizes even with idle connections. I know there were lots of horror stories of major memory usage early on. The memory growth climbed very quickly with active connections, but I wonder now with Rails 6.1+ if those issues have been ironed out.
Are you no longer concerned because memory usage dropped significantly?
How's the overall latency?
I remember seeing some benchmarks where ActionCable was using like 1-2gb of memory for around a thousand active connections with 95% percentile latency in the multi-second range to broadcast a message. I do see AnyCable makes huge improvements here and I love the idea of it but also not too sure how backwards compatible it is with Hotwire / Turbo Streams.
I've always thought Rails was good / fast enough but the ActionCable stuff worries me a little because a single low end VPS could happily handle a very solid amount of traffic (tens of thousands of daily page views, etc.) but once you start factoring in websocket connections that changes everything. Suddenly pages that have completed the request / response cycle are still on the hook to keep a ws connection open even if they're not doing anything that causes a state change.
For example does anyone else find Gitlabs diff lacking? It makes reviewing large patches painful, with the seemingly constant fetching of individual file diffs and inability to show large file diffs. The UI in general feels sluggish, especially when compared to something like Gerrit or GitHub.
I don't think I've seen that reported before and we have been working through some interesting to reproduce issues in recent milestones.
Would you mind opening an issue for this? Feel free to tag me (same name).
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/48790
This is closer to how git is used in the linux mailing lists but gitlab completely breaks that workflow. Github has added some support for that. And yeah, performance sucks, even for trivial patches.
Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/versi...
Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/revie...
Thanks for that comment. As you can expect, we notice it too. This is something the team is actively monitoring and working to improve (example: https://gitlab.com/gitlab-org/gitlab/-/issues/321691 being worked on in the current milestone).
I am curious: have you tried the file-by-file mode? Some users have given us very positive feedback on this feature, others not so much. It might be something that fits some users' habits but not others. But thought it was worth mentioning. We're actually considering and researching turning this on automatically for MRs over a certain size (https://gitlab.com/gitlab-org/gitlab/-/issues/212849 your thoughts would be very appreciated there, thanks!). https://docs.gitlab.com/ee/user/project/merge_requests/revie...
Not that it solves the root of the problem (that's being addressed too) yet this feature allows for really large MRs to be reviewed without having to render all the changes at once.
One of the things we're currently working on is putting monitoring in pace for all the of the diff limits - https://gitlab.com/gitlab-org/gitlab/-/issues/31063. The goal here is that we can further fine tune some of the limits in place to continue to help with larger merge requests.
The group also spent some time investigating ways to improve the blocking time for large merge requests and you can see some of the discussion around that here: https://gitlab.com/gitlab-org/gitlab/-/issues/295237.
The last issue I'll drop here is https://gitlab.com/gitlab-org/gitlab/-/issues/241841.
You can also see all of the other issues related to performance that the Code Review group has been working on in GitLab here: https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8...
Thanks again for the feedback - and know that this is something we are looking in to.
Bonus... you can enter for a chance to win a $75 Amazon gift card.
(And yes I filled out the survey).
Thid leeds to many hacks to get performance needed (jobs are merged in one big one for example). With many smaller jobs some pipelines run sometimes up to 50% slower than ssh + docker.
Also built-in caching is painfully slow. Our self hosted minio instance as custom cache is 10 times faster than Gitlab's local cache and this is absurd.
These are 2 main speed issues with me. As code reviewer large diff bad performance would be the 3rd issue. It lags even with my beefy workstation. Maybe adding JS functionality is needed for files in current viewport? I don't need syntax highlight and comments options on all 100 files at the same time but I want an option to scroll down and this functionality on currently viewed files
https://gitlab.com/gitlab-org/gitlab-runner/-/issues
Impatiently wafting for this so I don't have to use sluggish browser any more:
https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issu...
I'm also interested to see what kind of impact it has on large MRs, but do know it's not the answer for what happens in GitLab.
We are switching to GitHub. Which saddens me because I much prefer GitLab's interface. But I have lost the battle, due to GitLab's terrible performance.
https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-re...
"New predefined variables for job start time and pipeline created time"
https://gitlab.com/gitlab-org/gitlab/-/issues/22901
I know it hurts, I know it's probably not what devs at Gitlab aspire to, but I believe it is much needed. Possibly, an entire rewrite of some core aspects are needed. I have a lot of trouble selling Gitlab to my team. Everyone just wants to move to Github to have a simple UX that works.
GitHub's UX is simple because it doesn't even come close to what GitLab provides, even in the free tier, and their iteration is much slower. If GitHub had GitLab's features it'd have a complex in some places UX as well.
13.9 didn’t appear and I had to go looking. 13.10 hasn’t either. Blog “news” posts, unfiltered and patch releases all show up in RSS... why aren’t the monthly releases being included anymore?
https://about.gitlab.com/atom.xml currently shows 13.10 as the second entry.
I was subscribed to https://www.gitlab.com/atom.xml - at least, that's what Feedly's UI shows, but that URL doesn't seem to resolve at all. In my Feedly, the newest article was "building a better Heroku".
When you search for GitLab in Feedly, you also see that feed, without the 13.10 post. The "GitLab" source at top of search results shows "about.gitlab.com", 6k followers, but no 13.10 post.
I've directly added your atom.xml link so my situation is resolved for now. Thanks!
https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
- Syntax highlighting (for Python at least) is wonky.
- Changing profile pictures can take hours or days to propagate. Seems like a silly request, but I like changing my profile pic quickly.
- Metarepos (git repos using lots of submodules) are a mess in git and gitlab doesn't make it easier. It's either monorepo or manyrepo with no support for us inbetweeners.
- Frontend perf is snappier than some competitors, but not snappy /enough/.
- The search UI is bad. The widgets get in my way 90% of the time. And its slow.