On Wed, Apr 22, 2020 at 07:01:50PM +0200, Andrea Bolognani wrote:
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...
The check-dco script doesn't actually work if run against the main libvirt repo, as it ends up trying to use itself as a reference and failing to figure out which commits need checking. Of course that's a bug that's fixable, but in general I think it is better to not runthe job at all and thus eliminate any risk of false failures. 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 :|