[ https://issues.jboss.org/browse/JBDS-3593?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3593: ---------------------------------- Woo, CD! +100 for this idea. So right now, the job you created is just a wrapper for jbosstools-install-grinder.install-tests.matrix_master. Could you add more jobs to it? Note too that sometimes one of the many configs in that job (or the p2director one) fails while all the rest are fine. I'm not sure I would hold back a release if 1 out of 6 child jobs failed due to a network glitch. So... we would still need to manually review when a job in the buildflow was red to determine if it was 6/6 failures or 1/6 failures, like http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-install-gr... (which was fired again via Naginator and was then 6/6 success. Or else we'd need to enable a naginator-like approach to this build flow job... but do we want to have to rebuild ALL the test install jobs for ALL the platform configs, just because ONE child config failed? Seems like a total waste of cycles and time. Anyway, if it sounds like I'm crapping on this idea, I'm NOT. I do like this idea. :D I'm just trying to flesh out how we can use it given the current constraints we have for jobs that SOMETIMES fail for a non-reproduceable reason, which fix themselves when they respin. How would you handle that case? And what other verification steps can we add here to ensure a build is "ready to stage" or "ready to exit stage into prod" ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)