Frank Filz wrote on Thu, Apr 26, 2018 at 12:28:31PM -0700:
I'm guessing the testing has no way to track a cumulative state,
so it would
work better to have separate IDs.
Another possibility would be to have a single gerrit job from the centos
ci that triggers many builds (cthon, gluster etc) and then only sends
one update based on all the tests.
We already have everything needed to do that on centos ci - for example
the actual cthon04 test is split into these two:
- nfs_ganesha_cthon04 that does the actual build
- nfs-ganesha_trigger-cthon04-on-new-patch that listens to gerrit
events and triggers the build
We'd just need to remove all the nfs-ganesha_triggers-* (actually some
do work there, so rename the ones who do and remove just the trigger
part); then keep just one, but make that trigger all the actual build
projects instead.
It'd then automatically only post once with the aggregated result (I
assume it'd fail if any of the tests failed)
My only concern is whether or not it'd slow things down, I'm not sure
it'd trigger all jobs in parallel.. But then again I'm not sure how many
workers are allocated for ganesha so if we only have few it might not
make much difference?
--
Dominique