[jbosstools-issues] [JBoss JIRA] (JBIDE-19598) Use "Build other project (extended)" to cascade aggregation

[ https://issues.jboss.org/browse/JBIDE-19598?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19598: ------------------------------------ So with this change any of the 17 builds would trigger a rebuild of the JBT core & coretests aggregates. But today, we can collect changes into fewer respins using the composite site job (which spins at intervals rather than for EVERY upstream commit). The composite job ALSO does an install test to verify that everything can be installed into the current version of Eclipse. That job has been failing since we moved the target platform to use Eclipse Mars R (RC4/SR0) because it was using RC2 to do the install. (I fixed that yesterday and the job's back to blue/yellow.) So... that's a GOOD thing. It caught the fact that we can't install JBT 4.3.0.Beta2-SNAPSHOT bits onto RC2 because of the incompatible target platforms (p2 director installs can't do remediation). Losing this test, IMHO, would be bad. The overhead/maintenance is minimal. Causing many more aggregate builds to fire doesn't seem like a good thing. Why do we want to go back to something we specifically STOPPED doing a few years ago? -- Today, we run all the project builds based on SCM change, then fire the aggregates based on a composite site build. When we want to build the whole stack, we use a buildflow job. This achieves a balance of: * fairly frequent aggregate respins (every 3 hours, with re-checks every 30 mins if the attempt to build failed due to missing content) * light Jenkins slave load (composite job is faster and eats less time/disk space than 2 aggregate builds, which also have to suck down source zips from Github) https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... We used to have a cascade of jobs, linked together in their logical build order, then fired the aggregates based on a composite site build. We removed the inter-job linking to make maintenance easier (this was replaced by a buildflow job in 7.0). http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... Before that, we had all the jobs cause aggregates to fire (using a cascade of jobs, linked together in their logical build order). This was better than the old way, but harder to maintain as component job deps changed (more things depending on Base or Server, for example). So for 6.0 I added the composite install job. http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... Before that, we had all the projects firing the aggregate in no particular order, with no inter-job linking. This caused build failures and ate a lot of slave resources. http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... --- I guess my question, ultimately, is "what are we trying to solve by switching to a new model of job aggregation?" This JIRA doesn't actually state the problem we're trying to fix; it only says "we could use this plugin to remove the need for 1 job". Is the job so bad that its maintenance burden behooves its removal? -- This message was sent by Atlassian JIRA (v6.3.15#6346)