Topics

Jenkins builds


Peter Ulvestad
 

There haven't been any new packages built since the 24th of September, is this expected?
http://jmri.tagadab.com/jenkins/job/Development/job/Packages/

--
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/


Matthew Harris
 

Peter,

Looks like the upstream job has failing tests since then so, yes, that's expected. 

Basically, the 'Packages' job is kicked-off after a successful 'Builds':
http://builds.jmri.org/jenkins/job/Development/job/Builds/

This is so that only builds that pass our unit tests are packaged up as installable artifacts.

So, we need to figure out what's causing the test failure and fix it.

Hope that makes sense.

Best regards, 

Matt H


danielb987
 

2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.
...
So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel


Matthew Harris
 

On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.

...

So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel
Looks like that might be a different issue.

The test failure right now can be seen at:

http://builds.jmri.org/jenkins/job/Development/job/Builds/3632/testReport/jmri/ArchitectureTest/checkStandardStreams/

I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281

Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding). 

Best regards,

Matt H


Bob Jacobsen
 

Matt, thanks for the PR.

I’m looking into this on Jenkins.

It _seems_ to be related to Jenkins still being standardized on a very early Java 8 JDK.

Bob


On Oct 4, 2019, at 4:24 AM, Matthew Harris <@mattharris> wrote:

On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.

...

So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel
Looks like that might be a different issue.

The test failure right now can be seen at:

http://builds.jmri.org/jenkins/job/Development/job/Builds/3632/testReport/jmri/ArchitectureTest/checkStandardStreams/

I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281

Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding).

Best regards,

Matt H
--
Bob Jacobsen
@BobJacobsen


Randall Wood <rhwood@...>
 

Did figure out that build 101 of Java 1.8 introduced support for the root CA that signed LetEncrypt’s CA; as well as support for some new certificate signing algorithms; and removal of some no longer trusted signing algorithms, so it could simply be that something is not trusted somewhere if using an older Java 1.8.

Randall

On Oct 4, 2019, at 09:11, Bob Jacobsen <@BobJacobsen> wrote:

Matt, thanks for the PR.

I’m looking into this on Jenkins.

It _seems_ to be related to Jenkins still being standardized on a very early Java 8 JDK.

Bob


On Oct 4, 2019, at 4:24 AM, Matthew Harris <@mattharris> wrote:

On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.

...

So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel
Looks like that might be a different issue.

The test failure right now can be seen at:

http://builds.jmri.org/jenkins/job/Development/job/Builds/3632/testReport/jmri/ArchitectureTest/checkStandardStreams/

I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281

Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding).

Best regards,

Matt H
--
Bob Jacobsen
@BobJacobsen