Re: Use patchew to push successfully applied series to GitLab

[Daniel P . Berrangé]

On Thu, Sep 17, 2020 at 10:53:14AM +0200, Paolo Bonzini wrote:
> On 17/09/20 10:16, Philippe Mathieu-Daudé wrote:
> > patchew is currently pushing successfully applied series
> > (using the cover Message-ID as tag) to GitHub.
> > This is very handy (no need to apply patches manually):
> > https://github.com/patchew-project/qemu/tags
> > 
> > Can we push the same that to an equivalent GitLab account?
> > We could then have a script replying to the series if the
> > series fails CI. Doing so would save reviewer/tester time
> > (I'd rather have a series not failing on our CI tests before
> > starting to review/test it).
> 
> Yes, we could.  Indeed we could also look at the pipeline result instead
> of needing Patchew's custom testers (using a webhook).  It would be a
> bit on the heavy side for GitLab's resources; while right now they're
> still providing unlimited CI time, in principle the "gold" tier provides
> "only" 833 hours and a full CI run takes more or less 1.

Yep, this is a limitation of the patchew model where we have a central
service testing each contributors patches, instead of having the CI jobs
running in context of a user's fork and thus havin the CI usage cost
ammoritized across all user's accounts.

In a merge request workflow, this pretty much "just works" because the
CI jobs alwas run in the user's fork before the merge request is opened,
or when force-pushed.

Assuming we're not adopting a merge request workflow in the near term,
I wonder if we could do something clever to improve our mailing list
workflow CI to get jobs running mostly in user's forks.

A large number of contributors use "git-publish" to send patches. That
is already capable of optionally pushing to a public git server for
pull requests.

What if we used git-publish to always push to gitlab when submitting
patches, and have it include the gitlab ref in the cover letter.

That would trigger CI jobs in the user's fork, and patchew would not
have to run anything itself. It would merely monitor the user's fork
and report back to the list if the job failed. Patchew would ony then
have to run stuff in its own shared fork if the user didn't include
a gitlab ref in their cover letter.  At least this works for x86
Linux stuff. Doesn't work for any scenario needing custom runners.

Still if our regular contributors went this way, the shared fork
could have much lower build job load than we see today.

> So it would work great but we would have to set up our own runners,
> and/or have a cheaper pipeline for this gating CI.  Is that possible to
> configure in Gitlab?

The ideal situation is that we have one set of defined jobs that are
used universally by the person merging to git master, by patchew, by
any contributors before posting.

In terms of traditional build jobs, we have a huge number defined in
GitLab CI but it is only a partially overlapping set vs patchew,
principally because the GitLab jobs are x86 only. For the non-x86 stuff we 
would have to define
jobs that target custom runners and then have custom runners registered
against Patchew's account. If quota becomes a problem, we'd nede x86 custom
runners too.

The other useful part of patchew is the "checkpatch.pl" validation.
We should really create a job in GitLab CI that covers this, as it
is something that's useful for developers to get right before posting.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|