Hacker News Reader

Comment by ech | Hacker News Reader

gitlab is gearing up to be the one-stop-shop from development to production. i really like that. unifying the toolset developers and ops have to understand is really a boon for everybody involved.

merge restriction as a feature may sound silly, but in my experience, when driving organizations toward CI/CD, especially with "mature" organizations, having the computer say no instead of a human is a major facilitator in adoption of good practices. now we just need to protect tests in tree. (currently, i tend to favor tests as a git submodule, so we can prevent chronic offenders from altering/commenting tests that should pass)

plus U2F integration, so now i won't hear anymore how "terribly slow" it is to have to whip out a phone to grab a TOTP code...

View on HN

>merge restriction as a feature

Ability to enforce code review (allow users to approve merge requests but not push directly) has been demanded since 2014 [1] with no support from Gitlab. However, it looks like there's now a chance it's coming soon. [2]

[1] https://github.com/gitlabhq/gitlabhq/issues/6432 [2] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals.

it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.

Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?

This is nice, but does not solve the problem of giving a user the power to approve merge requests but not accidentally "git push origin master."

With protected branches you can prevent force pushes to master. You would have to do a manual merge and then git push origin master to cause a problem I think.

I don't generally use feature branches on solo projects. Working directly on master (and pushing origin master at arbitrary moments to back up my work) is a deeply ingrained habit.

A code review tool that's off by default and trivial to bypass in your sleep is a poor code review tool.

This is easy to prevent in Phabricator, which will block pushes to master if they contain changes not also present in an approved unit of code review. I run into that wall a few times a week, and am reminded to move my commits into a branch.

Thanks, good point. We're extending protected branches so all code will have to undergo a code review, see https://gitlab.com/gitlab-org/gitlab-ce/issues/18193

i am, i get people to use it, and it works well. but superuser2 is right. to be honest, i think we're touching to fundamental limitations in the git model that gitlab cannot solve without becoming rational team concert, and catering to a fundamentally different public.

> plus U2F integration, so now i won't hear anymore how "terribly slow" it is to have to whip out a phone to grab a TOTP code...

I don't know if this applies to you, but 1Password 6 has support for generating TOTP passwords (they have a neato QR scanner built in, or one can always just input the key or key URI by hand)

It's been a revolutionary change in my day-to-day frustration level

1Password TOTP https://blog.agilebits.com/2015/01/26/totp-for-1password-use... is great, we use it extensively at GitLab https://gitlab.com/gitlab-com/www-gitlab-com/commit/a2885089...

Thanks for your kind words. We indeed want to be the one-stop-shop from idea to production. For the complete scope see https://about.gitlab.com/direction/#scope

yeah i read the scope. but since the border between scheduling, configuration management, monitoring etc... is extremely blurry, with a high number of interconnection between systems, and lacking any kind of standard contract between them, i'm more wary about the introduction of these features.

The idea is to not do container scheduling in GitLab. We're considering adding some monitoring. Standard contracts are not easy but I think it is doable. We already shipped deploy to Kubernetes https://about.gitlab.com/2016/03/22/gitlab-8-6-released/ and we're working on more. For more information about our deployment vision please see about.gitlab.com/direction/cicd

Isn't U2F a Chrome only feature at the moment?

Are you using that seriously already?

firefox has a plugin that works fine from what i've heard from the others. i still rely by default on totp for generic dual factor auth, since i can provide already working solutions from web to ssh authentication. however, yes for web applications, some clients went the u2f options, and the users overwhelmingly prefer it. since u2f is getting very quickly traction in products (case in point, gitlab) and the user experience is so simpler for a similar level of security, it'll probably become my go to in the near future.

Firefox added it ~3 weeks ago under a flag in Nightly, should be in stable a few months from now.

Thanks! Glad you like the direction!

Reply on news.ycombinator.com