On Thu, Sep 17, 2020 at 5:36 PM Daniel P. Berrangé <berra...@redhat.com>
wrote:
>
> 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 :|
>
>
I agreed all, from these days experience on contributing to qemu, you
suggestion improve most aspect
I feel not good.
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
