This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org. 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
