If we would not have shipped new features and still did just just version control GitLab the company would not be viable. We're committed to shipping a single application for the whole DevOps lifecycle this year https://about.gitlab.com/2017/10/11/from-dev-to-devops/
But there are multiple performance tweaks en bugfixes going out every month, including this one.
Well, there's definitely a difference between periodically slowing down the new features for a month of additional focus on stability/performance improvements and 'just doing version control forever'.
Keep your fingers on the pulse of your customers. If the top comments in posts about your releases say "I wish they'd focus on quality more" even in a place where 'move fast and break things' is considered sage advice, then think of this as an indicator. If the performance improvements that have been going out every month are sufficient, the discussion would not focus on them as much.
I hope you see that I actively engage with our users and customers. We want to get the balance right. I think currently GitLab.com should be much more reliable and the RAM usage with should be lower. I'm happy with the improvements we are making in UX, polish, navigation, and loading times. They should all improve from today but we're making the right amount of progress.
Maybe a bit off-topic but some of our reliability improvements like Gitaly cause GitLab to use more memory. So improving non-functional requirements is not a single dimension.
Yes, do everything this anonymous person says, because their post has 3 upvotes.
Seriously though, listening to everything the community says is a certain recipe for failure. User feedback is an indicator, not more. Implementation details and the general direction of the software have to be based on sane decisions by the development team, not the community.
Please take my comment as playing devil's advocate, and not a negative "what do you think you're doing" question.
> If we would not have shipped new features and still did just just version control GitLab the company would not be viable.
Says who? I can name hundreds of enterprise software companies that don't ship new features on a regular basis and are still commercially very viable. In other words, what evidence do you have that if you spent 3 months just shipping performance improvements that it would slow your growth?
Thanks for asking. If you get back on the same pace after 3 months it would be acceptable. However I think this unlikely. From the linked page https://about.gitlab.com/handbook/ceo/#how-do-we-keep-shippi... "Don't ever slow down because it is very hard to recover from that. As soon as you stop shipping (for a big refactor, a security initiative, etc.) it is very hard to get back op to the old speed. The organization has accepted a slower rate and there are always enough reasons to go slower. You have to do the refactors and other things during the course of business, never slow down."
I think this is probably wrong. You need customers to love the product. Polish matters. Which is why github/slack is still used and loved more than bitbucket/hipchat.
Velocity for sake of velocity is not going to result in customer delight
I agree polish (user experience) is very important in winning people over. We think the worst user experience is between product categories in the DevOps lifecycle. Having to switch between JIRA, GitHub, circleCI, Artifactory, Ansible, and New Relic. We want to create a better flow. Therefore we have to balance polishing what we have with completing out vision of a single application for the DevOps lifecycle.
I'd love to use GitLab Issues over JIRA, but Issues is just so feature poor. I don't even need a complex bug tracker, but Issues doesn't solve any problem I can see, except very simple lists.
Just off the top of my head: How do you feel about CI/CD for gitlab? I mean in the sense of a publicly available unstable.gitlab.com where we warn users that everything will can get deleted at any time without notice? Maybe it is already possible?
> There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.
Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).
We are not accruing technical debt to ship these features. Quite the opposite, because we ship the minimum viable change we keep things as simple as possible, preventing un-needed complexity that can slow us down later.
I like the perspective I recently read here that you should avoid the debt with a high interest rate. If you got a fundamental concept wrong and that mistake spreads throughout your codebase that is much worse than an isolated piece of code that could be better.
And it's a very good thing that their product allows you to self-host, because I have zero-confidence in their ability to properly operate infrastructure.
But the attention to detail/quality on the product itself is lacking too. Don't get me wrong, I love gitlab as a product, but they really don't seem to care about working on anything that doesn't let them check another box on a marketing feature sheet.
Then this issue lingered for about a year before being closed because a customer filed a similar issue a couple months after I did... that other issue is still open though, so maybe they'll get around to it eventually:
https://gitlab.com/gitlab-org/gitlab-ce/issues/25535
I filed that issue after a Gitlab person here on hacker news specifically invited feedback on UX/UI issues, and I had just spent a frustrating time trying to track down a runner.
At some point I just stopped filing issues & started ignoring the issues I'd already filed. The times they decided to close issues because they'd been open a long time certainly didn't inspire me to waste any more time trying to help them improve the product.
Closing & re-opening and re-tagging and doing everything but actually fixing the issue is not confidence inspiring.
Gitlab is still a great product, but now when I run into things that might warrant opening an issue, I just find ways of dealing with them on my own.
James (Product Manager at GitLab) here. I've just picked up merge requests and have seen lots of feedback across multiple issues related to navigating between diffs/files when reviewing a merge request, and I want to make it better too.
There have been a few different solutions proposed including adding a file tree to the merge request interface, so you can quickly see a full list of the files and how they relate to each other. There is a design discovery issue for adding a file tree to the merge request interface https://gitlab.com/gitlab-org/gitlab-ce/issues/49189 scheduled for the next release to work out the UX in more detail.
Would a file tree make reviewing a merge request easier for you? Thanks for the feedback, and would love to hear more here, or on the issue.
Normally new duplicate issues are consolidated into the oldest issue, but since both issues had been open a while ago I kept the issue that had the most participants and discussion open.
3. Not showing a retry option to logged out users https://gitlab.com/gitlab-org/gitlab-ce/issues/19846 is a good improvement but since very few logged out users will see this message we don't consider it a bug.
4. Showing the original project next to the runner IDs makes a lot of sense. As you can see in the issue we are no longer closing feature proposals due to inactivity.
If you find ways of dealing with above things on your own that involve modifying GitLab please consider contributing them back.
Your response only furthers my point: if it doesn't show up on a marketing feature sheet, Gitlab doesn't seem to care to devote any resources to it.
Adding new features is great, but making sure that the user experience around existing features is smooth/sensible/not frustrating is pretty important too.
The approach of shipping 80% solutions which take 20% of the effort probably got Gitlab to where it is today. But at some point the company is large enough and has enough resources that it's reasonable to expect that the difficult parts of the problem and the "polish" get addressed too.
We care about making sure GitLab is polished end to end. We hired a UX team and now have two UX researchers on staff to find the biggest problems and fix them. An example of the outcome of that research is the SSH key experience https://gitlab.com/gitlab-org/ux-research/issues/53 of which the improvements shipped in this release.
The vision of GitLab of a single application for the whole DevOps lifecycle is large and even though we have 160 engineers (including support) we can't do it all.
So if there are people who are proficient in Ruby we would love for them to submit improvements and join the 2000 people who already contributed code to GitLab.
Hey, Matej here, I'm part of the UX team at GitLab. I understand that it can look like we don't spend much time polishing the user interfaces and experiences that much but I can assure that we do. We don't have a split in % on how much time we should spend polishing existing things but maybe it's something we should consider doing.
Our application covers the whole DevOps lifecycle which means it takes a lot of effort to upkeep existing and constantly ship new features, but we always strive to do our best.
Thanks for the feedback, I think it will trigger internal discussions on how much time we should spend polishing existing features and experiences.
Re "polishing", part of that might be treating complaints about experience getting worse differently than requests for improvements. E.g. from a different subthread here: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056 The report clearly is "this has been broken", but nothing in the issue suggests it being noticed as a regression and not just another potential for improvement, whereas the customer will remember "this worked, and they broke it".
Edit: I wanted to clarify that if you’ve observed any undesirable behavior, we welcome you to log it and we will address it as soon as we can. I see how my original comment made it seem like we ship untested code. That’s not the case as Sid mentioned below. That being said, there might be specific edge cases or scenarios we have not captured in our tests. So problems do appear from time to time. So I wanted to invite anybody to log any problem so that we can reproduce it as soon as we can and get it fixed.
Also as Sid mentioned, this feature was recently brought to Core so that more users now have access to it.
hitekker: See my edited comment above. We do not ship untested code. But any problems that users do find we definitely want them captured as soon as possible so that we can triage and fix.
I'm about to switch my team to Gitlab hosted for one reason: it's the only CI product I can find which has any notion of allowing the feature-branch/shared-repo model to have secrets protected from regular committers during builds.
Now if they could implement branch-specific secrets so I could manage ACLs amongst devs, senior devs, ops etc. then it would be near-perfect.
Secret variables are NOT output to Gitlab CI job logs... but if someone echos them, they WILL appear in the log. This may be obvious to some, but, I like to point it out nonetheless.
You've missed the important detail: Protected Variables in Gitlab aren't just hidden, they're not injected into builds which don't happen on Protected Branches.
What this means is that so long as I or another trusted person reviews the PR of a protected branch build, we can have high confidence the code isn't going to disclose secrets unintentionally, and that people aren't going to accidentally modify a build so it deploys outside the process.
This is great! But what I want is for it to go further - in a perfect system, I'd be able to set per-branch variables which are omitted if you're not on the right branch, and have branch protection managed by different sets of users - i.e. developers, lead developers, then testing/QA/UAT and finally production - which could just correspond to branch rules like uat/<whatever> preprod/<whatever> prod/<whatever> and allow PRs with different approvers to control the escalation process.
I think it would be a good feature to hide secrets from the log by searching for them and replacing them with something like [removed]. It would be best if it were done by a component that had the security locked down (maybe a process that you pipe it through) and it wouldn't prevent users from encrypting it to bypass the filter, but it would make it harder for misbehaving users to deny that they circumvented the security. It could also detect JSON stringified or base64'd secrets.
Wouldn't this be an unwinnable battle? If you can't print out the whole secret, you can print out each half of it, or one character at a time, each on a different line.
There's probably no way around the reality that users who have the ability to run arbitrary code on the CI server have access to the secrets.
Yeah. Maybe I shouldn't have suggested scrubbing base64'd secrets. What I have in mind is a usability feature, making it so users can't accidentally print out a secret that they're not supposed to print out.
I would have to admit that's useful as I've accidentally printed a secret key or two to publicly accessible jobs on TravisCI, and then had to scramble to rotate them :)
And now I'll take the secret, base64 it, add a space between each character, reverse the order and base64 it again. And then toss it through a round of AES256 with my key, all before echoing it.
Trying to prevent people from exfiltrating data by filtering the output stream is an impossible battle.
It wouldn't stop outright, and I tried to communicate that I knew it wouldn't in my comment. It would make it so if someone got caught doing that, it would be harder for them to deny that they did it deliberately, and you could throw the book at them. As it is now, they could print it out and say that they were just debugging, or they could even think it was permissible to print it out.
I can see the point of removing plausible deniability - it's just that I'm of the opinion that if something is known to be insecure it shouldn't try to pretend otherwise.
My favorite part of GitLab is the .gitlab-ci.yml and gitlab-runner workflow. My least favorite is how much RAM is required to run GitLab. You can't host your own on a $5 DigitalOcean vps. Does anyone know of any work being done on gitea/gogs, or other alternatives, that would support .gitlab-ci.yml and gitlab-runner?
@gitlab It would be awesome if you would split out GitLab-CI into something you can host separately as a direct competitor to Jenkins. Or maybe a stripped down "lite" version that could be hosted on small vps's. I know that doesn't fit your overall vision, or really help your bottom line, but it would help a lot of individuals and small organizations that need to self host for some reason (as in, there's a reason they can't use GitLab.com).
I haven't looked into Jenkin's in a couple years, so I'm not sure. My experience as the sysadmin of our Jenkin's server was decidedly negative. I was pretty happy when I was able to move to GitLab-CI instead of Jenkin's. It has it's issues, but at least I can upgrade it without breaking the entire instance....
Does anyone know if Gitlab is now on a monthly release schedule?
Today is exactly one month after Gitlab 11.0 release.
It seems Gitlab is finally on Rails 5.0, hopefully they move to Rails 5.2 soon. It seems the whole Rails Ecosystem, Shopify, Zendesk, Gitlab, AirBnb, Discourse is now catching up to the latest release.
This is neat, but the pricing tiers are a bit extreme. I’d like to use static code analysis, but this is only available in platinum ($99/month/user [0]) or ultimate (unknown price - call sales).
I currently use Core for free and going from $0 to $100k seems pretty steep for a fairly simple feature that Github has partially implemented in their free tier.
Good point. We're thinking about making security open source at the merge request level but charging for project, group, and instance level metrics. What would you think of that?
That’s better. I actually don’t necessarily mind paying or jumping through hoops, but it’s such a massive jump for what I see as a feature that I’ll likely have to buy a 3rd part product for much less than that.
I’d like some way to use it manually as a low cost project and then pay for convenience.
There’s a group in my org looking at MicroFocus at $1200/build seat.
If you want to use it manually consider looking at the .gitlab-ci.yml template included in GitLab EE. If you do it manually you'll probably have to send the results to an artifact to see them.
Their pricing is a bit extreme, especially when it comes to counting users. Its the biggest reason why we haven't paid for any tier. I'd love to pay for at least the Starter, but we have 20 external developers (but only 2 active ones) and 6 internal developers (all active). It'd be nice if there were different tiers between the users (single repo users are cheaper than multiple repo users, and the admin users doesn't count).
My biggest issue with GitLab is that it's core 95% use case UX is just significantly weaker than GitHub's.
This may seem subjective, and it certainly is to some extent, but I've used both platforms pretty extensively and I find GitHub's UX so much cleaner and more usable every time.
I use both GL and GH every day. And I find GH's UX is much weaker, e.g. it doesn't remember last used sort options on the issues page which is huge annoying.
I actually find the opposite. Besides a self hosted option, the biggest reason I chose GL at work was because I found the UX so much better than GH. Like miles better. (Don't even get me started on the terribly named "Pull Request" which GL properly names as "Merge Request".
It would help if gitlab's web interface could make it possible to renew letsencrypt security certificates more easily than running local commands and cutting and pasting the certbot handshake string, then the SSL public and private keys. I have to do this every 3 months for the website for an open source project. Or if gitlab could sell ssh access to a VM host (for this purpose, not to use do any other significant computing) at reasonable cost.
GitLab now uses Let's Encrypt for self-hosted installations. We plan to start using it for GitLab pages sites with custom domains and applications deployed with Auto DevOps. The issue for the latter is at https://gitlab.com/gitlab-org/gitlab-ce/issues/41355
Yeah, but they're still calling it "Gitlab Flavored Markdown". The release was just about how they're changing the renderer. This does nothing to reduce the confusion with the fact that there are still two "flavors" of Markdown called different things but referred to with the same acronym, but I guess now both rendered by the same backend? This makes no sense to me.
The additions GitLab has expand on Markdown. For example, if you comment with a string of hexidecimals larger than 8 characters, GitLab will try to link to the commit if it finds one. For issue 1, the reference pattern in #1. This is convenient in cases where you want to cross reference merge requests, snippets, and others, without copy pasting the links. The docs explain it better than I could: https://docs.gitlab.com/ce/user/markdown.html
But in general, GitLab supports Markdown, with a few extensions.
I wished this update came with gitlab.com-wide project search. But looks like the "improved search" still didn't include that.
Github-wide search is great! I wish Gitlab had something like that. That's one of the things that's stopping me from switching 100% to Gitlab.
The site-wide search on GitHub allows me to explore code snippets, learn how someone else uses the "foo" syntax, see the trending repos in a given language, and so much more.
If you have the Gold Plan (for a group) on GitLab.com, you will be able to use the Epics feature for that group. See [1].
If you have any other plan (including Free), you should not see that field (or at most you should see a dismissable upgrade UI). That doesn’t seem to be case currently. I’ve logged an issue to correct this. [2]
Note, it's only a paid feature for private projects on GitLab.com. Public projects get all features of Gold for free: https://about.gitlab.com/open-source/
Same issue, it seems to have become an "eierlegende Wollmilchsau" (German for Swiss Army knife, but with a negative conotation).
I recently move to gittea[1] for the very reason that I dont need 90%+ of Gitlabs features. Also Gitlab chews up RAM and IO, while gittea is barely noticeable even on a low end server.
[1] https://gitea.io/
I have to agree a bit on the "Eierlegende Wollmilchsau". Features are not everything, regressions and degraded core functionality impact current users, which will impact whether you are getting new users in the long run.
For example, recently the number of characters before line-wraps in the MR diff view changed. Not sure if this was intentional or accidental. I know two companies using Gitlab, both based the max-line length in their style-guide on what fit the diff-viewer. I guess Gitlab became a worse tool for code-reviews for them with that change.
"You need to optimize for the people not using your product yet because it is missing features." doesn't sound very fair to current users, and I don't think that will work long term.
Thanks for replying to this. The fluid settings will help, although it is not quite the same on small laptop screens as before the change.
At the same time I think the issue you link really highlights what some people have been saying: stable quality of the core product hasn't had the focus that customers would like it to have.
Apparently you changed the line-wrapping behaviour twice in a year, without even realising that 1) you changed it, and 2) that some of your customers rely on this being stable.
Of course you could argue that it was silly to rely on this behaviour, and that the new behaviour is in fact an improvement. But personally I think functional stability is
important to all customers, and the fact that this was not a deliberate change is odd.
Obviously such a small change will never drive away customers, but I do think quality is the difference between having users and having users that are also ambassadors that will recommend your product.
Thanks for that quote. I wrote that when we were much smaller. I now release it was worded to strong. I'll change it to something like: "You need to optimize for all people, both the current users and people not using GitLab yet because it is missing features" when I land.
I've asked Victor to look into the max line length change.
I agree that GitLab is using too much RAM. Stan Hu, all time MVP record holder, will start working to reduce this. Options are removing Ruby code in Gitaly 1.1 and using multi threading in the application server.
For every release GitLab gives an MVP award to the community member who contributes in an impactful way to that release. Stan has earned it the most times: https://about.gitlab.com/mvp/
Have you ever old software to an enterprise customer? Making your product look special by offering a bazillion features they will never use is surprisingly successful.
Only if you actually then invest some time in selling it. I've had radio silence from their sales team when requesting to purchase an self-hosted licence. The one thing I know about Microsoft (GitHub) - they _get_ enterprise sales.
Hi Simon, I work at GitLab. Sorry for the radio silence. I do know we prioritize follow up based on company size & order size. If a smaller company requests a few licenses it can slip through the cracks. I've tracked down your record in our CRM and am escalating to our sales team so that you get a response.
In our environment, a vendor would probably be better served to offer a no frills basics thing and then just sell customization support (or painless customization). You could probably check off every bulletpoint imaginable and then we would still have things that need customizing.
That sounds like Atlassian's products to me. That can backfire after a few years of use when every page is customized to hell and back and no one knows how it works.
No ones giving money for bugfixes, folks. People who pay money choose the product they are going to buy according to feature lists. Good enough quality is good enough.
It all depends on pro and cons. And if the gitlab people are doing this rather than fixing bug, is because they estimated that this is their best move right now.
In GitLab Starter, we have the export issues to CSV functionality, which includes two time tracking fields: time estimate and time spent. Is this the kind of reporting functionality you are looking for?
How does the code search compare to best-in-class search tools like SourceGraph? Looks like GitLab is still missing a lot of important utilities like informative tooltips, jump-to-definition, etc.
Sourcegraph CEO here. :) Sourcegraph works really well with GitLab so you can search and browse code (with IDE-like code intelligence) across all of your GitLab EE/CE/.com repositories efficiently. See https://about.sourcegraph.com/docs/config/repositories#gitla... or just set it up with the one-command installation instructions on the homepage.
A month of nothing but performance tweaks and bugfixes would be great though.
We have to balance shipping new features https://about.gitlab.com/handbook/ceo/#how-do-we-keep-shippi... with performance tweaks and bugfixes.
If we would not have shipped new features and still did just just version control GitLab the company would not be viable. We're committed to shipping a single application for the whole DevOps lifecycle this year https://about.gitlab.com/2017/10/11/from-dev-to-devops/
But there are multiple performance tweaks en bugfixes going out every month, including this one.
The big performance tweak in this release is the merge request view refactor https://about.gitlab.com/2018/07/22/gitlab-11-1-released/#me... which makes loading merge requests much faster but there are 35 other performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
There were 141 bugs closed in this release https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...
Well, there's definitely a difference between periodically slowing down the new features for a month of additional focus on stability/performance improvements and 'just doing version control forever'.
Keep your fingers on the pulse of your customers. If the top comments in posts about your releases say "I wish they'd focus on quality more" even in a place where 'move fast and break things' is considered sage advice, then think of this as an indicator. If the performance improvements that have been going out every month are sufficient, the discussion would not focus on them as much.
I hope you see that I actively engage with our users and customers. We want to get the balance right. I think currently GitLab.com should be much more reliable and the RAM usage with should be lower. I'm happy with the improvements we are making in UX, polish, navigation, and loading times. They should all improve from today but we're making the right amount of progress.
Maybe a bit off-topic but some of our reliability improvements like Gitaly cause GitLab to use more memory. So improving non-functional requirements is not a single dimension.
Yes, do everything this anonymous person says, because their post has 3 upvotes.
Seriously though, listening to everything the community says is a certain recipe for failure. User feedback is an indicator, not more. Implementation details and the general direction of the software have to be based on sane decisions by the development team, not the community.
Please take my comment as playing devil's advocate, and not a negative "what do you think you're doing" question.
> If we would not have shipped new features and still did just just version control GitLab the company would not be viable.
Says who? I can name hundreds of enterprise software companies that don't ship new features on a regular basis and are still commercially very viable. In other words, what evidence do you have that if you spent 3 months just shipping performance improvements that it would slow your growth?
Thanks for asking. If you get back on the same pace after 3 months it would be acceptable. However I think this unlikely. From the linked page https://about.gitlab.com/handbook/ceo/#how-do-we-keep-shippi... "Don't ever slow down because it is very hard to recover from that. As soon as you stop shipping (for a big refactor, a security initiative, etc.) it is very hard to get back op to the old speed. The organization has accepted a slower rate and there are always enough reasons to go slower. You have to do the refactors and other things during the course of business, never slow down."
I think this is probably wrong. You need customers to love the product. Polish matters. Which is why github/slack is still used and loved more than bitbucket/hipchat.
Velocity for sake of velocity is not going to result in customer delight
I agree polish (user experience) is very important in winning people over. We think the worst user experience is between product categories in the DevOps lifecycle. Having to switch between JIRA, GitHub, circleCI, Artifactory, Ansible, and New Relic. We want to create a better flow. Therefore we have to balance polishing what we have with completing out vision of a single application for the DevOps lifecycle.
I'd love to use GitLab Issues over JIRA, but Issues is just so feature poor. I don't even need a complex bug tracker, but Issues doesn't solve any problem I can see, except very simple lists.
Thank you for this nice reply (and all the great work of course)!
You're welcome! :) Thanks for caring about GitLab. New features vs. bugfixes is a hard balance and feedback helps us to find it.
Congrats on shipping!
Sometimes new features appear straightforward but the implementation details can be complicated. For example,
https://gitlab.com/gitlab-org/gitlab-ce/issues/18157
Just off the top of my head: How do you feel about CI/CD for gitlab? I mean in the sense of a publicly available unstable.gitlab.com where we warn users that everything will can get deleted at any time without notice? Maybe it is already possible?
We are working on doing incremental rollout of new features on GitLab.com and on having an artificial load on our staging site.
There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.
We also test new features on dev.gitlab.org that runs a nightly build and is used by some of our team members.
> There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.
Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).
Details of how to toggle the canary environment can be found in our handbook: https://about.gitlab.com/handbook/engineering/#canary-testin...
Shout out to you Sid for remaining so engaged in the community in a constructive, science backed and transparent manor as the company has grown.
Are you not accruing technical debt to ship these features, then? That’s not sustainable.
We are not accruing technical debt to ship these features. Quite the opposite, because we ship the minimum viable change we keep things as simple as possible, preventing un-needed complexity that can slow us down later.
I mean by putting off refactoring and bug fixes that are being constantly eschewed in favor of adding features.
We care a lot about having an optimal level of technical debt and write about this on our blog and in our handbook https://www.dropbox.com/s/kdctzn1ha8z666l/Screenshot%202018-...
I like the perspective I recently read here that you should avoid the debt with a high interest rate. If you got a fundamental concept wrong and that mistake spreads throughout your codebase that is much worse than an isolated piece of code that could be better.
It really really would.
And it's a very good thing that their product allows you to self-host, because I have zero-confidence in their ability to properly operate infrastructure.
But the attention to detail/quality on the product itself is lacking too. Don't get me wrong, I love gitlab as a product, but they really don't seem to care about working on anything that doesn't let them check another box on a marketing feature sheet.
A selection of some issue I've filed...
Only took around a year to fix: https://gitlab.com/gitlab-org/gitlab-ce/issues/25388
Then this issue lingered for about a year before being closed because a customer filed a similar issue a couple months after I did... that other issue is still open though, so maybe they'll get around to it eventually: https://gitlab.com/gitlab-org/gitlab-ce/issues/25535
Here's one from two years ago that's still open: https://gitlab.com/gitlab-org/gitlab-ce/issues/19846
It's possible that issue is actually fixed now. I don't know and I don't care anymore.
Here another issue from 2 years ago: https://gitlab.com/gitlab-org/gitlab-ce/issues/19656
I filed that issue after a Gitlab person here on hacker news specifically invited feedback on UX/UI issues, and I had just spent a frustrating time trying to track down a runner.
At some point I just stopped filing issues & started ignoring the issues I'd already filed. The times they decided to close issues because they'd been open a long time certainly didn't inspire me to waste any more time trying to help them improve the product.
Closing & re-opening and re-tagging and doing everything but actually fixing the issue is not confidence inspiring.
Gitlab is still a great product, but now when I run into things that might warrant opening an issue, I just find ways of dealing with them on my own.
Ugh I hear you. I have been following this issue for nearly a year: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056
I cannot believe its not fixed it. They made the MR file view completely useless for us. It was a new "feature" that actually made things worse.
James (Product Manager at GitLab) here. I've just picked up merge requests and have seen lots of feedback across multiple issues related to navigating between diffs/files when reviewing a merge request, and I want to make it better too.
There have been a few different solutions proposed including adding a file tree to the merge request interface, so you can quickly see a full list of the files and how they relate to each other. There is a design discovery issue for adding a file tree to the merge request interface https://gitlab.com/gitlab-org/gitlab-ce/issues/49189 scheduled for the next release to work out the UX in more detail.
Would a file tree make reviewing a merge request easier for you? Thanks for the feedback, and would love to hear more here, or on the issue.
Also sad to see how reports about regressions appear to turn into "feature requests", that then are nice to have instead of important.
Thanks Daniel. I'm a Product Manger at GitLab. The relative submodule fix is scheduled as a Deliverable for 11.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/25535 – sorry it's taken so long.
Normally new duplicate issues are consolidated into the oldest issue, but since both issues had been open a while ago I kept the issue that had the most participants and discussion open.
I wanted to give some context issue by issue.
1. We consider stopping an environment https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 a new feature, not a bug.
2. Relative submodule links are planned for 11.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/37356
3. Not showing a retry option to logged out users https://gitlab.com/gitlab-org/gitlab-ce/issues/19846 is a good improvement but since very few logged out users will see this message we don't consider it a bug.
4. Showing the original project next to the runner IDs makes a lot of sense. As you can see in the issue we are no longer closing feature proposals due to inactivity.
If you find ways of dealing with above things on your own that involve modifying GitLab please consider contributing them back.
Your response only furthers my point: if it doesn't show up on a marketing feature sheet, Gitlab doesn't seem to care to devote any resources to it.
Adding new features is great, but making sure that the user experience around existing features is smooth/sensible/not frustrating is pretty important too.
The approach of shipping 80% solutions which take 20% of the effort probably got Gitlab to where it is today. But at some point the company is large enough and has enough resources that it's reasonable to expect that the difficult parts of the problem and the "polish" get addressed too.
We care about making sure GitLab is polished end to end. We hired a UX team and now have two UX researchers on staff to find the biggest problems and fix them. An example of the outcome of that research is the SSH key experience https://gitlab.com/gitlab-org/ux-research/issues/53 of which the improvements shipped in this release.
We balance new major features, performance improvements and bug fixes https://news.ycombinator.com/item?id=17588352 and polish.
The vision of GitLab of a single application for the whole DevOps lifecycle is large and even though we have 160 engineers (including support) we can't do it all.
So if there are people who are proficient in Ruby we would love for them to submit improvements and join the 2000 people who already contributed code to GitLab.
Hey, Matej here, I'm part of the UX team at GitLab. I understand that it can look like we don't spend much time polishing the user interfaces and experiences that much but I can assure that we do. We don't have a split in % on how much time we should spend polishing existing things but maybe it's something we should consider doing.
Just to give an example of a recent redesign of an existing feature that I was involved in, it can be found here: https://gitlab.com/gitlab-org/gitlab-ee/issues/6089
Our application covers the whole DevOps lifecycle which means it takes a lot of effort to upkeep existing and constantly ship new features, but we always strive to do our best.
Thanks for the feedback, I think it will trigger internal discussions on how much time we should spend polishing existing features and experiences.
Re "polishing", part of that might be treating complaints about experience getting worse differently than requests for improvements. E.g. from a different subthread here: https://gitlab.com/gitlab-org/gitlab-ce/issues/39056 The report clearly is "this has been broken", but nothing in the issue suggests it being noticed as a regression and not just another potential for improvement, whereas the customer will remember "this worked, and they broke it".
They introduced "squash" and "modify commit message" on the last release. It worked 1 time on the 4 times I tried.
If you could log a bug here with any details that would be great! https://gitlab.com/gitlab-org/gitlab-ce
Thanks!
Edit: I wanted to clarify that if you’ve observed any undesirable behavior, we welcome you to log it and we will address it as soon as we can. I see how my original comment made it seem like we ship untested code. That’s not the case as Sid mentioned below. That being said, there might be specific edge cases or scenarios we have not captured in our tests. So problems do appear from time to time. So I wanted to invite anybody to log any problem so that we can reproduce it as soon as we can and get it fixed.
Also as Sid mentioned, this feature was recently brought to Core so that more users now have access to it.
Please stop using your customers as your Quality Control.
I get Gitlab is going for "breadth over depth", but your company must ensure the features being promoted actually work.
Shipping untested code does not build confidence.
We're not using our customers as quality control.
Changes can be minimal but they have to meet our definition of done https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU... that includes tests.
I assume the relevant product manager (Victor) hasn't heard this complain before but that doesn't show from his answer.
This feature was open sourced in 11.0 https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#sq... after many people requested it https://gitlab.com/gitlab-org/gitlab-ce/issues/34591 but the code has been in use by users since GitLab 8.17 (Feb 22, 2017) https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1024 so I think that is why Victor assumed this was a user specific problem.
hitekker: See my edited comment above. We do not ship untested code. But any problems that users do find we definitely want them captured as soon as possible so that we can triage and fix.
Fixing merge conflicts is completely broken for me ever since they introduced it.
Or cleaning up their work-in-progress, currently there are around 11307 issues open: https://gitlab.com/gitlab-org/gitlab-ce/issues
Among other things we use the issue tracker for feature proposals. So it is not a good proxy of work in progress.
I'm about to switch my team to Gitlab hosted for one reason: it's the only CI product I can find which has any notion of allowing the feature-branch/shared-repo model to have secrets protected from regular committers during builds.
Now if they could implement branch-specific secrets so I could manage ACLs amongst devs, senior devs, ops etc. then it would be near-perfect.
Secret variables are NOT output to Gitlab CI job logs... but if someone echos them, they WILL appear in the log. This may be obvious to some, but, I like to point it out nonetheless.
You've missed the important detail: Protected Variables in Gitlab aren't just hidden, they're not injected into builds which don't happen on Protected Branches.
What this means is that so long as I or another trusted person reviews the PR of a protected branch build, we can have high confidence the code isn't going to disclose secrets unintentionally, and that people aren't going to accidentally modify a build so it deploys outside the process.
This is great! But what I want is for it to go further - in a perfect system, I'd be able to set per-branch variables which are omitted if you're not on the right branch, and have branch protection managed by different sets of users - i.e. developers, lead developers, then testing/QA/UAT and finally production - which could just correspond to branch rules like uat/<whatever> preprod/<whatever> prod/<whatever> and allow PRs with different approvers to control the escalation process.
I think it would be a good feature to hide secrets from the log by searching for them and replacing them with something like [removed]. It would be best if it were done by a component that had the security locked down (maybe a process that you pipe it through) and it wouldn't prevent users from encrypting it to bypass the filter, but it would make it harder for misbehaving users to deny that they circumvented the security. It could also detect JSON stringified or base64'd secrets.
Wouldn't this be an unwinnable battle? If you can't print out the whole secret, you can print out each half of it, or one character at a time, each on a different line.
There's probably no way around the reality that users who have the ability to run arbitrary code on the CI server have access to the secrets.
Yeah. Maybe I shouldn't have suggested scrubbing base64'd secrets. What I have in mind is a usability feature, making it so users can't accidentally print out a secret that they're not supposed to print out.
I would have to admit that's useful as I've accidentally printed a secret key or two to publicly accessible jobs on TravisCI, and then had to scramble to rotate them :)
And now I'll take the secret, base64 it, add a space between each character, reverse the order and base64 it again. And then toss it through a round of AES256 with my key, all before echoing it.
Trying to prevent people from exfiltrating data by filtering the output stream is an impossible battle.
It wouldn't stop outright, and I tried to communicate that I knew it wouldn't in my comment. It would make it so if someone got caught doing that, it would be harder for them to deny that they did it deliberately, and you could throw the book at them. As it is now, they could print it out and say that they were just debugging, or they could even think it was permissible to print it out.
I can see the point of removing plausible deniability - it's just that I'm of the opinion that if something is known to be insecure it shouldn't try to pretend otherwise.
My favorite part of GitLab is the .gitlab-ci.yml and gitlab-runner workflow. My least favorite is how much RAM is required to run GitLab. You can't host your own on a $5 DigitalOcean vps. Does anyone know of any work being done on gitea/gogs, or other alternatives, that would support .gitlab-ci.yml and gitlab-runner?
@gitlab It would be awesome if you would split out GitLab-CI into something you can host separately as a direct competitor to Jenkins. Or maybe a stripped down "lite" version that could be hosted on small vps's. I know that doesn't fit your overall vision, or really help your bottom line, but it would help a lot of individuals and small organizations that need to self host for some reason (as in, there's a reason they can't use GitLab.com).
GitLab CI used to be a completely separate application. When we integrated both we learned of the emergent benefits of an integrated application https://about.gitlab.com/handbook/product/single-application... and we want to keep those.
I understand the need to have GitLab use less memory, I commented in https://news.ycombinator.com/item?id=17588073 about our plans.
BTW If you want to use just GitLab CI and are a current GitHub customer you can do that https://about.gitlab.com/features/github/
I am running GitLab on $5 DigitalOcean droplet but the tradeoff I have to create a Swap file worth 2GB.
I use Gitea and Drone and I love it - the flow is pretty similar
isn't `.gitlab-ci.yml` just the same as a jenkins pipeline?
I haven't looked into Jenkin's in a couple years, so I'm not sure. My experience as the sysadmin of our Jenkin's server was decidedly negative. I was pretty happy when I was able to move to GitLab-CI instead of Jenkin's. It has it's issues, but at least I can upgrade it without breaking the entire instance....
Does anyone know if Gitlab is now on a monthly release schedule?
Today is exactly one month after Gitlab 11.0 release.
It seems Gitlab is finally on Rails 5.0, hopefully they move to Rails 5.2 soon. It seems the whole Rails Ecosystem, Shopify, Zendesk, Gitlab, AirBnb, Discourse is now catching up to the latest release.
Yeah, GitLab has been on a monthly release schedule since October 2011: https://about.gitlab.com/2015/12/17/gitlab-release-process/
Yep, GitLab releases on the 22nd of everyone month. Here’s a list of releases.
https://about.gitlab.com/releases/
They have been releasing new updates on the 22th of every month for over two years now.
GitLab is not on rails 5.0 yet. But it's on its way.
This is neat, but the pricing tiers are a bit extreme. I’d like to use static code analysis, but this is only available in platinum ($99/month/user [0]) or ultimate (unknown price - call sales).
I currently use Core for free and going from $0 to $100k seems pretty steep for a fairly simple feature that Github has partially implemented in their free tier.
[0] https://about.gitlab.com/pricing/#gitlab-com
Good point. We're thinking about making security open source at the merge request level but charging for project, group, and instance level metrics. What would you think of that?
That’s better. I actually don’t necessarily mind paying or jumping through hoops, but it’s such a massive jump for what I see as a feature that I’ll likely have to buy a 3rd part product for much less than that.
I’d like some way to use it manually as a low cost project and then pay for convenience.
There’s a group in my org looking at MicroFocus at $1200/build seat.
If you want to use it manually consider looking at the .gitlab-ci.yml template included in GitLab EE. If you do it manually you'll probably have to send the results to an artifact to see them.
Thanks, I’ll check it out. Keep up the good work, it’s a tough business model- but admirable.
Thank you!
Their pricing is a bit extreme, especially when it comes to counting users. Its the biggest reason why we haven't paid for any tier. I'd love to pay for at least the Starter, but we have 20 external developers (but only 2 active ones) and 6 internal developers (all active). It'd be nice if there were different tiers between the users (single repo users are cheaper than multiple repo users, and the admin users doesn't count).
My biggest issue with GitLab is that it's core 95% use case UX is just significantly weaker than GitHub's.
This may seem subjective, and it certainly is to some extent, but I've used both platforms pretty extensively and I find GitHub's UX so much cleaner and more usable every time.
I use both GL and GH every day. And I find GH's UX is much weaker, e.g. it doesn't remember last used sort options on the issues page which is huge annoying.
So this is subjective.
maybe gitlab’s goal to integrate the whole of the software dev life cycle into a single UI isn’t the UX what you want.
(Personally I find it a lifesaver)
I also find github's UI/UX much cleaner and easier to work with, gitlab tries to put too much stuff in one page and they are have low contrast.
I actually find the opposite. Besides a self hosted option, the biggest reason I chose GL at work was because I found the UX so much better than GH. Like miles better. (Don't even get me started on the terribly named "Pull Request" which GL properly names as "Merge Request".
It would help if gitlab's web interface could make it possible to renew letsencrypt security certificates more easily than running local commands and cutting and pasting the certbot handshake string, then the SSL public and private keys. I have to do this every 3 months for the website for an open source project. Or if gitlab could sell ssh access to a VM host (for this purpose, not to use do any other significant computing) at reasonable cost.
GitLab now uses Let's Encrypt for self-hosted installations. We plan to start using it for GitLab pages sites with custom domains and applications deployed with Auto DevOps. The issue for the latter is at https://gitlab.com/gitlab-org/gitlab-ce/issues/41355
Does anyone find it annoying that both Github and Gitlab have their own flavor of markdown which they both call GFM?
I guess you didn't read the 11.1 release notes where they stated they were standardising on http://commonmark.org/ right?
Yeah, but they're still calling it "Gitlab Flavored Markdown". The release was just about how they're changing the renderer. This does nothing to reduce the confusion with the fact that there are still two "flavors" of Markdown called different things but referred to with the same acronym, but I guess now both rendered by the same backend? This makes no sense to me.
The additions GitLab has expand on Markdown. For example, if you comment with a string of hexidecimals larger than 8 characters, GitLab will try to link to the commit if it finds one. For issue 1, the reference pattern in #1. This is convenient in cases where you want to cross reference merge requests, snippets, and others, without copy pasting the links. The docs explain it better than I could: https://docs.gitlab.com/ce/user/markdown.html
But in general, GitLab supports Markdown, with a few extensions.
I wished this update came with gitlab.com-wide project search. But looks like the "improved search" still didn't include that.
Github-wide search is great! I wish Gitlab had something like that. That's one of the things that's stopping me from switching 100% to Gitlab.
The site-wide search on GitHub allows me to explore code snippets, learn how someone else uses the "foo" syntax, see the trending repos in a given language, and so much more.
All my issues (on gitlab.com) now have an "Epic" field, but I can't find anywhere to actually create an epic. Am I missing it somewhere?
If you have the Gold Plan (for a group) on GitLab.com, you will be able to use the Epics feature for that group. See [1].
If you have any other plan (including Free), you should not see that field (or at most you should see a dismissable upgrade UI). That doesn’t seem to be case currently. I’ve logged an issue to correct this. [2]
[1] https://docs.gitlab.com/ee/user/group/epics/
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/49484
That’s an Enterprise feature, depends on what subscription you have.
Note, it's only a paid feature for private projects on GitLab.com. Public projects get all features of Gold for free: https://about.gitlab.com/open-source/
I just do not understand what they spend their time on. No ones giving out points for more checkmarks in a feature list, folks.
As a transparent company, our roadmap (what we spend time on) along with our strategy (why we spend it there) is public. https://about.gitlab.com/direction/ https://about.gitlab.com/strategy/ The "breadth over depth" section might help to shed some understanding.
Same issue, it seems to have become an "eierlegende Wollmilchsau" (German for Swiss Army knife, but with a negative conotation).
I recently move to gittea[1] for the very reason that I dont need 90%+ of Gitlabs features. Also Gitlab chews up RAM and IO, while gittea is barely noticeable even on a low end server. [1] https://gitea.io/
I have to agree a bit on the "Eierlegende Wollmilchsau". Features are not everything, regressions and degraded core functionality impact current users, which will impact whether you are getting new users in the long run.
For example, recently the number of characters before line-wraps in the MR diff view changed. Not sure if this was intentional or accidental. I know two companies using Gitlab, both based the max-line length in their style-guide on what fit the diff-viewer. I guess Gitlab became a worse tool for code-reviews for them with that change.
"You need to optimize for the people not using your product yet because it is missing features." doesn't sound very fair to current users, and I don't think that will work long term.
I’m not aware that we intentionally changed anything with the line wraps.
But if you go to User Settings > Preferences, you can select between Fixed vs Fluid layout width. Do you recall making any changes here recently?
Here’s an issue with some discussion on the design of fixed vs fluid options. https://gitlab.com/gitlab-org/gitlab-ce/issues/27347
Thanks for replying to this. The fluid settings will help, although it is not quite the same on small laptop screens as before the change.
At the same time I think the issue you link really highlights what some people have been saying: stable quality of the core product hasn't had the focus that customers would like it to have. Apparently you changed the line-wrapping behaviour twice in a year, without even realising that 1) you changed it, and 2) that some of your customers rely on this being stable. Of course you could argue that it was silly to rely on this behaviour, and that the new behaviour is in fact an improvement. But personally I think functional stability is important to all customers, and the fact that this was not a deliberate change is odd.
Obviously such a small change will never drive away customers, but I do think quality is the difference between having users and having users that are also ambassadors that will recommend your product.
Thanks for that quote. I wrote that when we were much smaller. I now release it was worded to strong. I'll change it to something like: "You need to optimize for all people, both the current users and people not using GitLab yet because it is missing features" when I land.
I've asked Victor to look into the max line length change.
I landed and changed the text https://gitlab.com/gitlab-com/www-gitlab-com/commit/bc9087f9... Thanks for noticing and caring.
Very cool to see that feedback is appreciated and that change happens fast at Gitlab.
I agree that GitLab is using too much RAM. Stan Hu, all time MVP record holder, will start working to reduce this. Options are removing Ruby code in Gitaly 1.1 and using multi threading in the application server.
What is all time MVP record holder? Is it a rails community competition or something else?
For every release GitLab gives an MVP award to the community member who contributes in an impactful way to that release. Stan has earned it the most times: https://about.gitlab.com/mvp/
The direct translation, "egg-laying wool-milk-sow", gets the point across fairly well.
Have you ever old software to an enterprise customer? Making your product look special by offering a bazillion features they will never use is surprisingly successful.
Only if you actually then invest some time in selling it. I've had radio silence from their sales team when requesting to purchase an self-hosted licence. The one thing I know about Microsoft (GitHub) - they _get_ enterprise sales.
Hi Simon, I work at GitLab. Sorry for the radio silence. I do know we prioritize follow up based on company size & order size. If a smaller company requests a few licenses it can slip through the cracks. I've tracked down your record in our CRM and am escalating to our sales team so that you get a response.
Thanks William. I look forward to hearing from them. We only have 10 days left on our trial.
In our environment, a vendor would probably be better served to offer a no frills basics thing and then just sell customization support (or painless customization). You could probably check off every bulletpoint imaginable and then we would still have things that need customizing.
That sounds like Atlassian's products to me. That can backfire after a few years of use when every page is customized to hell and back and no one knows how it works.
The biggest picture thing we're spending our time on is creating a single application for the whole DevOps lifecycle. See https://about.gitlab.com/2017/10/11/from-dev-to-devops/ for more context.
No ones giving money for bugfixes, folks. People who pay money choose the product they are going to buy according to feature lists. Good enough quality is good enough.
Perhaps not, but they stop paying money because of bugs.
It all depends on pro and cons. And if the gitlab people are doing this rather than fixing bug, is because they estimated that this is their best move right now.
It seems like an even mix of new features, enhancements to existing features, and maintenance.
some of their features are also pretty half-ass baked. like time tracking.
Is there any particular time tracking feature you are interested in?
at least some kind of reports..
Please see https://gitlab.com/gitlab-org/gitlab-ce/issues/25532 that has links to open an source application to generate reports from GitLab data. And the tracking issue to add this to GitLab is https://gitlab.com/gitlab-org/gitlab-ce/issues/37605
In GitLab Starter, we have the export issues to CSV functionality, which includes two time tracking fields: time estimate and time spent. Is this the kind of reporting functionality you are looking for?
https://docs.gitlab.com/ee/user/project/issues/csv_export.ht...
Anything else that makes sense that we can log an issue for?
if I need to write my own tool, than I probably don't need to pay EE for csv exports, since your api can export issue's as well.
How does the code search compare to best-in-class search tools like SourceGraph? Looks like GitLab is still missing a lot of important utilities like informative tooltips, jump-to-definition, etc.
GitLab code search is not on the same level as SourceGraph that has much more language dependent features.
Sourcegraph CEO here. :) Sourcegraph works really well with GitLab so you can search and browse code (with IDE-like code intelligence) across all of your GitLab EE/CE/.com repositories efficiently. See https://about.sourcegraph.com/docs/config/repositories#gitla... or just set it up with the one-command installation instructions on the homepage.
Anyone using their OIDC integration should carefully read the release notes. Some form of migration action will be required.
This is about OpenID Connect, see https://about.gitlab.com/2018/07/22/gitlab-11-1-released/#st...
> external systems can no access all merge requests reliably
Typo? Should it be "now"?
The most innovative source control product in the market just got even better. :)