Re: Widening reach for ... code?
I can weigh in a little bit on this. I'm not going to go in depth here,
but I can definitely answer a few of the questions raised.
On 2020-08-24 13:06, Robert Varga wrote:
Hello,I migration to GitLab would basically mean throwing the Jenkins infra
out the door and having to rebuild all jobs as GitLab pipelines.
Technically we could make MRs (GitLab's parlance of Merge Request vs
GitHub's of Pull Requests / PR) work in Jenkins, but we've not done any
work along that in that direction. We do, however, have PRs working with
Jenkins (I'll get more into this in a bit)
2) Patch review process. Let's not kid ourselves, GitLab and GitHubTo be brutally honest (and this it truly my personal opinion here) both
GitLab and GitHub suck when it comes to code review. The review process
that Gerrit pushes creates a much better experience IMO. It is, however,
a really huge hurdle for folks and a lot our time with new developers
seems to be spent on just getting them familiar with Gerrit Way
3) The straight-up choice of GitLab -- I think this is something theFor various reasons I'm not going to into the whys or wherefores of why
GitLab is the current preferred choice of LFIT for SaaS SCM/CI
solutions. I'll gladly talk to you off record on this one ;)
But to name just a few
* We have a way to enforce DCO requirements that stops changes from
coming in without them. GitHub is an after the fact CI validator which
makes it really hard to actually enforce and very easy to game
* GitLab supports repo hierarchies because of how they built their
system. GitHub is a flat namespace. We already flatten our repo
hierarchies (not that ODL has many, but it does have a few) by
translating the '/' to '-'. ONAP and other LFN properties already have
issues being able to really understand where a particular repo
originally came from in the GitHub mirror because of this flattening.
* GitLab CI is more flexible in that we can leverage pipeline templates
/ libraries. GitHub Actions is still lacking in this though they do have
the GitHub Actions marketplace, it makes it harder to have standard job
* GitLab CI allows us to do dynamic builders ala Jenkins as long as
we're doing it against AWS or GCE.
* It's possible with GitHub to do some amount of dynamic builders by
leveraging AWS CodeBuild but then you're splitting your GitHub Actions
into two logically distinct parts. The GHA workflow itself, and then the
CodeBuild "job" portion that runs out in a CodeBuild defined
environment. Each CodeBuild project has to be pre-created before it can
be used and we would essentially be back to having to come up with a
nice way (ala jjb) to manage those CodeBuild projects and their life
cycle :-/ (yes they can be managed from the aws cli, but we're still
then having to basically write a jjb type replacement that does stuff
* One pro for GitHub that is a con for GitLab (not this affect ODL, but
it does affect some other LFN properties) EasyCLA support exists for
GitHub, it does not currently exist for GitLab.
With that out of the way, I would like to make a counter-proposal:Technically we can do this already. There is a GitHub plugin for Gerrit
that will allow us to create Gerrit side changes if a PR is opened a
GitHub repository. That being said, I've played with this workflow over
on GerritHub and it seriously hurts.
The workflow operates in the following manner:
* PR is created in GitHub
* For every commit in the PR a new Gerrit change is created
* If changes are requested on the PR then the modified code ends up
coming in as a _separate_ Gerrit Change. The requested changes are _not_
communicated back to the open PR, they happen internal to the Gerrit
system. If the system is configured to not send mail to unknown entities
(as all of ours are) then the person that raised the PR, if they have
never logged into the Gerrit system, will _not_ get notified.
* Once the change is merged on the Gerrit side, the code gets mirrored
back to GitHub but the PR does not get closed.
Additionally, and I don't know if this is just a limitation of how
GerritHub operates, the PRs don't automatically create Gerrit Changes.
You have to explicitly force a PR refresh cycle.
Now, some of this is obviously just a failing in how the plugin
operates, but the biggest issue here is that the GitHub/GitLab workflow
is very much an anti-pattern in Gerrit. Gerrit requires that Change-ID
to be able to track different patches across the life of a single
change. You don't get that in GitHub/GitLab, you just got a very messy
patch series to contend with.
I mean we already have a read-only mirror on GitHub for each and every--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation