On Wed, 2020-04-22 at 17:20 +0100, Daniel P. Berrangé wrote: > On Wed, Apr 22, 2020 at 06:11:13PM +0200, Andrea Bolognani wrote: > > Why is it that we want to skip those branches, anyway? I get why > > they're not necessary in a MR-based workflow, but we're not quite > > there yet... > > This was an inexact way to stop the checks running against the > master repo, after the patches have been merged. > > The flaw in this is that a user could indeed open a merge request > that uses a "master" or "v*maint" branch in their private fork, > rather than a named feature branch. > > Really we want it to run on all commits in a user's fork, but > not run in the master repos post-merge. I still don't understand why we would want to single out those branches and not run the DCO check on them. What harm would it cause? It takes around a minute to run it, which is significantly less than the other jobs running during the prebuild stage... > > Actually, now that we're using GitLab as the primary repository, > > how are we ensuring commits without DCO don't slip in? We had a > > hook that took care of that on libvirt.org - was something like > > that introduced on GitLab? > > It isn't as strict as before - there's a push rule that requires > the word "Signed-off-by" in the commit message: > > https://libvirt.org/newreposetup.html Oh, cool! I had forgotten about that detail since reviewing the document, and it's nice to know that we still have at least some level of protection on that front :) -- Andrea Bolognani / Red Hat / Virtualization
