On Mon, Aug 24, 2020 at 5:07 PM Andrew Grimberg < agrimberg@...> wrote: On 2020-08-24 13:48, Thanh ha wrote:
> See inline.
>
> (Include's Robert's fixes)
>
> On Mon, Aug 24, 2020 at 4:06 PM Robert Varga <nite@...
> <mailto:nite@...>> wrote:
>
> Hello,
>
> in today's (lightly advertised) TWS call, Casey raised the question of
> migrating our infrastructure to GitLab in a bid to attract more
> contributions.
>
> Unfortunately a straight-up migration seems unfeasible to me due to a
> multitude for things that come into play:
>
> 1) Jenkins integration, or are we saying we would also switch CI? If so,
> how does that work with our JJB infra/CSIT?
>
>
> Either way would require modifying JJB to support the new SCM system
> GitLab and the trigger mechanism would be quite a bit different than
> what we have with Gerrit (PRs vs Gerrit Trigger) so this wouldn't be a
> simple change of backends. Concern here for me is who would lead this
> effort. I think we'd need LF support considering the community does not
> have the available cycles to do this.
>
> 2) Patch review process. Let's not kid ourselves, GitLab and GitHub
> patch review workflow is utterly different from Gerrit. I do not know
> what the multi-branch support looks like these days, but last time I
> checked GitHub's workflow was woefully inadequate to support multiple
> concurrent streams (to test: do you have 'cherry-pick'-like option?)
>
>
> The cherry-pick option in GitHub (likely GitLab too but I'm not familiar
> with it) is CLI with a command like `git cherry-pick master` or similar.
> Personally I like this method but that's because I'm in the weeds of Git
> often, I can see the value in an easy button for this like Gerrit has.
>
> Sadly, the GitHub / GitLab model is via PRs (basically branches) which
> are not equivalent to patch reviews like Gerrit. So a change of system
> would require all the committers to unlearn Gerrit.
>
> 3) The straight-up choice of GitLab -- I think this is something the
> community should have a choice in. Then again, we probably have far less
> technical participation than would be needed to make a well-informed
> decision.
>
>
> I think this would be better received if the LF did the background work
> to make this work for the community, however I feel LF is no longer
> actively engaged in LFN project's day to day development cycle. Meaning
> LF is going to drop GitLab on us and tell us to do the legwork to make
> all of our projects work with that. This kind of transition would
> require a significant amount of work for the community to take on to
> transition the CI bits and adjust our workflows. Considering there's a
> lack of people to lead this kind of work... I worry that this is an
> exercise in frustration.
We are doing some leg work on this. We've been getting semi-deep in the
weeds the following of late:
GitHub + Azure Pipelines
GitHub + Jenkins (we already support several projects in this config)
GitHub + GitHub Actions
GitLab + GitLab CI
You'll note a distinct lack of GitLab + Jenkins in that list ;)
OPNFV had a proposal just last week for an RE managed lift from Gerrit +
Jenkins -> GitLab + GitLab CI transition. The reason they were targetted
is because they don't really have that many jobs to transition and in
all honesty, it wouldn't be much of a change in how they do things now
outside of the use of GitLab instead of Gerrit. The reason being that
most of the work in OPNFV actually happens in third-party CI systems.
On the ODL side of things, moving the regular build jobs will be the "easy" part as it's migrating some maven shell scripts to the new CI system. CSIT on the other hand would be the difficult part. I think not only to get the shell scripts working on the new platform but also figuring out how to re-route the triggering mechanisms. Like when autorelease passes, build the integration-test project with a specific parameter that is different than when autorelease fails.
There's a few specific trigger paths that would require someone to fully understand how all the ODL jobs are mapped to carry out. Also since CSIT also spins up a lab using heat, if we're lucky the heat templates will work out of the box but if not it would take time to figure out the workflow here. Another thing would be there're several ODL jobs that are tied directly to Gerrit comment triggers, this would need to be rewritten for GitLab I would assume.
In any case, while I wouldn't be against moving to a new CI system. However with consideration of ODL's current available resources... It would be a significant disruption for the ODL community and would require either LF to lead the work, or someone is able to step up to do that and see it to completion.
Thanh
> With that out of the way, I would like to make a counter-proposal:
>
> How about LF(N) investing some dev/test resources into making it
> possible for outside contributions to be mirrored back to Gerrit?
>
>
> This is possible as I've used GerritHub (http://gerrithub.io/) before
> and it worked (although over 8 years ago when I tried it), it was quite
> clunky but maybe it's better now. I'm not sure if GerritHub is
> proprietary or if there's available a Gerrit plugin for this feature.
> Not sure how hard it would be to replicate this feature but at least it
> seems to be possible.
No, it's still clunky and nasty IMO. That's me having just tried it
again about 1.5 - 2 months ago. The plugin that GerritHub uses is
available to us, but I've not tried using it directly, just via their
system.
-Andy-
> I mean we already have a read-only mirror on GitHub for each and every
> ODL project, and we should be able to make the same thing work on GitLab
> (or any other force). We are utterly lacking the ability to review pull
> requests -- in any way, shape or form!
>
> What I mean is that while the repository mirrors are read-only, at least
> GitHub provides API access, which should allow our infra to monitor
> those repositories for incoming PRs. When a PR is created, updated,
> closed, these actions should automagically be turned into equivalent
> patch (series) being created in Gerrit. I do believe this is feasible,
> as Gerrit provides a superset of required operations. It would also mean
> any such PR would be serviced by our CI.
>
> This would allow people to contribute, potentially provide Git{Hub,Lab}
> reviews of PRs, extending the reach, while still not requiring any sort
> of infrastructure or workflow migration. It also is very much aligned
> with LF's mission to promote use of free software -- Gerrit is
> (Apache-licensed) FOSS after all!
>
> Hence, Casey, is this something LF has any capability/interest of
> picking up in a bid to actively make the world a better place?
>
> Regards,
> Robert
>
>
>
>
--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation
|
