GitLab 11.1 released with security dashboards and enhanced code search (opens in new tab)

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.

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?

Thank you for this nice reply (and all the great work of course)!

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.

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.

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.

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.

Fixing merge conflicts is completely broken for me ever since they introduced it.

Among other things we use the issue tracker for feature proposals. So it is not a good proxy of work in progress.

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 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.

The direct translation, "egg-laying wool-milk-sow", gets the point across fairly well.

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.

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.

Perhaps not, but they stop paying money because of bugs.

Is there any particular time tracking feature you are interested in?

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....

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.

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.

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/

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.

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.