On 07/06/2016 10:37 PM, Mainzer, Gal wrote: > Is it possible to have a gerrit gating criteria on a periodic stable > build as well? > > If there are some "slow" tests that can run once/twice a day (and not > on every patch), we may be able to have a periodic run which once it > reaches to a certain stable level it can become gating (merges will > be permitted only if it's not broken) - this methodology is kind of a > "find the break after patch is merged" but finding the breaking merge > and reverting it can be pretty easy. > > Thanks, Gal
The mechanics of how Gerrit operates do not allow for something like this as you can't depend on the state of external resources. Patch merge gating is completely depending upon the voting state of the current patch and if the parent patch(es) are merged. The workflow we're testing puts the gating in as a mechanism of the jobs that are being executed for validation as it's a combined scoring from any triggered jobs that gives the final vote. Trying to depend upon the state of a job that isn't part of the triggered set is an extremely resource intensive operation given how our jobs operate. We would have to code up a very "lite" job that essentially exit with the status of some other job. The issue with that is that it would have tie up resources that could be better served actually building or testing, particularly as of yesterday all of our build instances are used once and then discarded, which means that we have to spool up an instance, connect to it, start the job, and then despool the instance which consumes an instance from other jobs until it's cleared out. -Andy- -- Andrew J Grimberg Systems Administrator Release Engineering Team Lead The Linux Foundation
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
