4 ms·

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 r

by ech 10y ago

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

darklajid 10y ago
Isn't U2F a Chrome only feature at the moment? Are you using that seriously already?
- ech 10y ago
  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.
- connorshea 10y ago
  Firefox added it ~3 weeks ago under a flag in Nightly, should be in stable a few months from now.
Snappy 10y ago
Thanks! Glad you like the direction!
mdaniel 10y ago
> 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
- sytse 10y ago
  1Password TOTP https://blog.agilebits.com/2015/01/26/totp-for-1password-users/ 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/a288508900583b3a14f8a162376c9aa257ac71f4 https://gitlab.com/gitlab-com/www-gitlab-com/commit/a2885089...
sytse 10y ago
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 https://about.gitlab.com/direction/#scope
- ech 10y ago
  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.
  - sytse 10y ago
    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/ 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
superuser2 10y ago
>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 https://github.com/gitlabhq/gitlabhq/issues/6432 [2] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220
- ech 10y ago
  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.
  - sytse 10y ago
    Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approve-merge-request/ https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?
    - superuser2 10y ago
      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."
      - sytse 10y ago
        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.
        superuser2 10y ago
        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.
deleted 10y ago
[deleted]

by ech 10y ago

darklajid 10y ago

Isn't U2F a Chrome only feature at the moment? Are you using that seriously already?

ech 10y ago
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.
connorshea 10y ago
Firefox added it ~3 weeks ago under a flag in Nightly, should be in stable a few months from now.

Snappy 10y ago

Thanks! Glad you like the direction!

mdaniel 10y ago

> 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

sytse 10y ago
1Password TOTP https://blog.agilebits.com/2015/01/26/totp-for-1password-users/ 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/a288508900583b3a14f8a162376c9aa257ac71f4 https://gitlab.com/gitlab-com/www-gitlab-com/commit/a2885089...

sytse 10y ago

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 https://about.gitlab.com/direction/#scope

ech 10y ago
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.
- sytse 10y ago
  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/ 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

superuser2 10y ago

>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 https://github.com/gitlabhq/gitlabhq/issues/6432 [2] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220

ech 10y ago
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.
- sytse 10y ago
  Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approve-merge-request/ https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?
  - superuser2 10y ago
    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."
    - sytse 10y ago
      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.
      - superuser2 10y ago
        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.

deleted 10y ago

[deleted]