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:
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