[jbosstools-issues] [JBoss JIRA] (JBIDE-13817) aggregate site build should produce junit test output to confirm if the contents of the zips fetched from the upstream composite site match 100% the contents of the produced aggregate site

[ https://issues.jboss.org/browse/JBIDE-13817?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-13817: ------------------------------- Description: The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). It also tried to pull the list of zips from a local zip.list.txt file [0] rather than just going right to the composite site. [0] http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which: * reads the upstream composite site [1], and ** for each child site listed, *** downloads a zip matching the last CI build for that project **** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report. Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found. [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/, There is also this file [2] produced by this job [3], which might make things easier: [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun... [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job... was: The old way to pull zips is with https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... but it is an incomplete solution as it has never verified that the zips were the same content as the aggregate site (they could have changed AFTER the aggregate was built). The new way should be an *optional* mojo (runs only for aggregate builds, not individual project builds) which: * reads the upstream composite site [1], and ** for each child site listed, *** downloads a zip matching the last CI build for that project **** IFF the contents of that downloaded zip match the IU versions of the aggregate site we just built, then produce a passing JUnit xml report. If the contents differ, return an error report. Aggregate jobs will therefore need to be updated to look for these JUnit reports, and mark the build UNSTABLE (yellow) if any non-passing results are found. [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/, There is also this file [2] produced by this job [3], which might make things easier: [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trun... [3] http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/job... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira