ah - I was imagining the builds doing the aggregation was not having
any
explicit override but using the released/specific TP version; but yeah -
if the -Dtpc.version
is set on *every* job then yeah. Need to think how to fix that.
We could go back to the previous approach where the version used is
controlled by parent pom, but you asked that we move away from that. :)
Add a test to the aggregation; i.e. validate content of the site.
You mean like these?
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
Of course that just tests "can we install this stuff?" not "are the
contents what we expect?"
Could be a basic test for bundle version matching or even better
actually
have a test that verifies the updated TP actually fixes a bug; but that
might be tricky to do in many cases :(
If you wanted to diff the contents of the JBDS update site w/ the
contents of the JBDS target platform, you might be able to achieve some
sort of "was the expected output the same as the input?" test, but you
could also achieve the same thing by simply reading the console log to
see which TP was used to build. :)
We don't need to validate the projects was *built* with this
specific TP;
we just need to run the tests against this TP.
Ah, but you DO need to verify that the aggregates are BUILT with the
maximum TP version. It's just the individual component projects that are
build w/ minimum and tested w/ maximum.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com