8:10 a.m.
Due to recent changes to the way we run the Jenkins jobs, using explicit
commandline overrides to specify the target platform version used, the
new Juno-based 4.22.2 target platform listed in the parent pom was NOT
used to run the jobs for 4.0.1.CR1a / 6.0.1.CR1a.
(More manual steps / things to update == more chance something will be
forgotten.)
The result of this is that aggregate builds did not run with, and
therefore include, the newer m2e-wtp 0.17.0 bits
(https://issues.jboss.org/browse/JBIDE-13603). Thanks to Len for
exposing this problem.
So... I'm respinning the aggregate sites today (JBT WTP, JBT Core, JBT
Core Tests, JBDS Core + Installer).
I could also respin the individual projects too, if we want to verify
that all ours tests are run against the newer TP. Please advise.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
5:15 p.m.
new Juno-based 4.22.2 target platform listed in the parent pom was
NOT
used to run the jobs for 4.0.1.CR1a / 6.0.1.CR1a.
Which jobs was it exactly this was missed in ?
(More manual steps / things to update == more chance something will
be
forgotten.)
An idea i've had lately is actually that we have tests for the various TP changes
to verify the version we think is in there is actually in there. Then it would
not wait until after the build to be noticed.
I could also respin the individual projects too, if we want to verify
that all ours tests are run against the newer TP. Please advise.
hmm - we really need to get moving on being able to run the tests against
something already built instead of a rebuild.
Created
for
that.
For this time I say we rely on QE's tests.
/max
10:50 p.m.
On 03/26/2013 06:15 PM, Max Rydahl Andersen wrote:
> new Juno-based 4.22.2 target platform listed in the parent pom
was NOT
> used to run the jobs for 4.0.1.CR1a / 6.0.1.CR1a.
Which jobs was it exactly this was missed in ?
All of them. Templated jobs == global mistakes when important steps like
this are missed. :(
An idea i've had lately is actually that we have tests for the
various
TP changes
to verify the version we think is in there is actually in there. Then it
would
not wait until after the build to be noticed.
Sounds like a reasonable idea, but what would you test? The JBDS
installer content? The build logs? Because only JBDS installers
*include* the TP; the rest simply refer to it (in the logs) when
building and testing. And if it was OK in JBDS installer build but wrong
elsewhere, testing the installer wouldn't conclusively prove that you
also built the projects or the JBT aggregate using the correct TP
version(s).
Created
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
for that.
That's a mailing list. Did you mean a new JIRA?
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11:57 p.m.
On Tue, Mar 26, 2013 at 11:50:06PM -0400, Nick Boldt wrote:
On 03/26/2013 06:15 PM, Max Rydahl Andersen wrote:
>>new Juno-based 4.22.2 target platform listed in the parent pom was NOT
>>used to run the jobs for 4.0.1.CR1a / 6.0.1.CR1a.
>Which jobs was it exactly this was missed in ?
All of them. Templated jobs == global mistakes when important steps
like this are missed. :(
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.
>An idea i've had lately is actually that we have tests for the
various
>TP changes
>to verify the version we think is in there is actually in there. Then it
>would
>not wait until after the build to be noticed.
Sounds like a reasonable idea, but what would you test?
Add a test to the aggregation; i.e. validate content of the site.
Could be a basic teest 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 :(
The JBDS
installer content? The build logs? Because only JBDS installers
*include* the TP; the rest simply refer to it (in the logs) when
building and testing. And if it was OK in JBDS installer build but
wrong elsewhere, testing the installer wouldn't conclusively prove
that you also built the projects or the JBT aggregate using the
correct TP version(s).
We don't need to validate the projects was *built* with this specific TP;
we just need to run the tests against this TP.
>>https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>for that.
That's a mailing list. Did you mean a new JIRA?
bad paste, meant: https://issues.jboss.org/browse/JBIDE-13869
/max
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
11:33 a.m.
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
4288
days inactive
4289
days old
jbosstools-dev@lists.jboss.org
4 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Nick Boldt