Ask Your Question
1

Should we migrate development to GitLab?

asked 2018-11-07 00:09:09 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

Our current code review and continuous integration stack is built on Gerrit, Buildbot, and Bugzilla. It works well enough, but there is certainly room for improvement. Bugzilla and Buildbot in particular are showing their respective ages.

One suggestion that has been popping up recently, both at SharkFest and in private emails, has been to migrate to GitLab. GitLab provides a cohesive interface for all of the things we currently do with separate products: code reviews, continuous integration, issue tracking, and a wiki. I will post answers in favor of Gerrit, GitLab, and other options below. Please add votes, comments, and other options as needed.

If we do decide to migrate it probably won't happen immediately. There are a lot of moving parts which in turn require careful planning and preparation.

edit retag flag offensive close merge delete

4 Answers

Sort by ยป oldest newest most voted
2

answered 2018-11-07 00:09:52 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

We should migrate to GitLab, either self-hosted or SaaS.

edit flag offensive delete link more

Comments

From an operations standpoint GitLab's SaaS and self-hosting options are both attractive. They would solve the following issues:

  • Although I liked Gerrit's "bring your own" authentication in theory, it's been crap in practice. We regularly end up with duplicate accounts which must be fixed manually.
  • Bugzilla integration is currently broken due to a j2bugzilla issue.
  • Buildbot integration works well, but Buildbot itself is a dead end. The version we use (0.8) only supports Python 2, but 0.9 and later appear to be geared towards internal teams instead of public projects.
  • This would give us a bonus migration path away from Moin, our wiki software.
Gerald Combs gravatar imageGerald Combs ( 2018-11-07 00:10:55 +0000 )edit

I am all for the Gitlab route. Additionally it is easier for newcomers to get used to the workflow

rknall gravatar imagerknall ( 2018-11-07 09:58:24 +0000 )edit

I'd go with GITLAB.

Pros:

  • UI much more attractive, intuitive and versatile compared to gerrit
  • workflow similar to github (merge requests)
  • well supported and developed
  • integrated builders (gitlab-runner)
  • install on-premises (good option compared to use of saas that can fail) full integration with wiki/issue tracker with automated citation/closing/referencing of objects (https://about.gitlab.com/2016/03/08/g...)
  • web editor (but it doesn't amend the commit, it rather creates a new commit in the MR)

Cons:

  • The MR must be merged as a whole, no option to cherry-pick a commit via UI. This requires the MR to be rebased before merging if we stick with a linear commit history (as it is now)
  • no way to comment a commit message in a specific point (a general comment on the commit is possible however)
  • no way to comment a block of code or a token within ...
(more)
crondaemon gravatar imagecrondaemon ( 2018-11-07 14:08:12 +0000 )edit

Reviewing the link to GitLab features posted by Dario I noted the following:

  1. No blocking with negative approval to prevent a merge: https://gitlab.com/gitlab-org/gitlab-...
  2. A tl;dr; issue on making GitLab better for Open Source projects: https://gitlab.com/gitlab-org/gitlab-...

As I understand it, using Gerrit, currently we do fast-forward merges, and GitLab supports this. What is the difference between this and merge commits? If it makes the history more verbose then I'm not in favour of that.

grahamb gravatar imagegrahamb ( 2018-11-09 09:06:02 +0000 )edit
  1. => Right, I forgot about that. That's feature I really miss.

You can configure gitlab MR to accept FF merges only. That means no merge commits and a linear history. Basically the same behavior we have on gerrit ATM.

crondaemon gravatar imagecrondaemon ( 2018-11-09 10:05:04 +0000 )edit
1

answered 2018-11-07 00:09:33 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

We should stay with Gerrit. It's not perfect, but it's better than the alternatives.

edit flag offensive delete link more

Comments

I would keep Gerrit, and maybe switch from Buildbot to Jenkins. The Jenkins/Gerrit integration works quite well.

Lori gravatar imageLori ( 2018-11-07 09:50:53 +0000 )edit

The key bits of the current setup for me are

  1. Ease of interacting with Gerrit at the command line with git-review.
  2. Ease of review\comment with Gerrit UI.
  3. Ability to correct commit message in Gerrit UI without needing to pull \ edit \ push.

I would hope that any replacement at least offers similar capabilities otherwise I'd regard that as a regression.

One capability I would like is a link from a commit as shown on the buildbot to the associated Gerrit change. This is wanted to easily determine which change has broken a build without having to update my local repo and look for the commit by hash (which is all buildbot shows).

grahamb gravatar imagegrahamb ( 2018-11-07 11:45:44 +0000 )edit
0

answered 2018-11-07 00:12:44 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

We should do something else as described in a comment below.

edit flag offensive delete link more
-1

answered 2018-11-07 00:13:16 +0000

this post is marked as community wiki

This post is a wiki. Anyone with karma >750 is welcome to improve it.

We should migrate to GitHub.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-11-07 00:09:09 +0000

Seen: 160 times

Last updated: Nov 07