[ https://issues.jboss.org/browse/JBIDE-21145?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-21145: ------------------------------------ To explain our current process / job interconnections again... * composite site job performs an install to see if anything has changed. If so, it kicks off the aggregate jobs. * when aggregates are done, they check to see if anything has changed (currently this is just a buildinfo.json diff, not a p2diff -- but we can add that in JBDS-16970). If nothing new, no new publish. * then JBDS is built. When done, check to see if anything has changed (currently this is just a buildinfo.json diff, not a p2diff -- but we can add that in JBDS-16970). If nothing new, no new publish. * then discovery sites are built & versionwatch verification is kicked (in parallel, downstream from JBDS build) * Once discovery is refreshed, THEN we do p2 director and install-grinder install tests of JBT and JBDS. Because these tests require a fully-functional JBT, JBDS, Central, and EA site. SO... if you're suggesting that the outcome of a p2diff in the JBT aggregate jobs should control whether or not to fire the install tests, we can certainly do that. But we already prevent running those install tests by preventing upstream from firing downstream. If no new JBT, then no new JBDS, and therefore no new discovery, so no new install tests. Right now the mechanism to determine if/when to fire install tests is "new JBT? new JBDS? new discovery? OK, then new install tests." And that's currently controlled by 2 levels of buildinfo.json SHA diffing - first in JBT, then again in JBDS. So... TL;DR, I think we actually agree here. Scary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)