Travis started setting _JAVA_OPTIONS, which overrides our Maven memory settings and puts us again at risk of random build failures:
https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/
I have removed _JAVA_OPTIONS in .travis.yml on supported branches of GeoTools and GeoServer.
Kind regards,
--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
My fix is ineffective. Success depends on how the age of the Travis worker image. The newer workers fail:
Builds on these images succeed:
Build image provisioning date and time
Fri Jul 7 18:52:25 UTC 2017
Builds on these images fail:
Build image provisioning date and time
Tue Aug 29 02:50:02 UTC 2017
It is a lottery. Affects both GeoTools and GeoServer and all branches.
Kind regards,
Ben.
On 12/09/17 13:11, Ben Caradoc-Davies wrote:
Travis started setting _JAVA_OPTIONS, which overrides our Maven memory settings and puts us again at risk of random build failures:
https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/I have removed _JAVA_OPTIONS in .travis.yml on supported branches of GeoTools and GeoServer.
--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
I have applied a new fix to all of the branches. My original fix was likely getting overwritten by some undocumented Travis stage order. Initial tests indicate that the new fix works on the new (August) Travis worker images. It is not needed on the old ones but does no harm.
Of all places I found the fix in some sort of Japanese aggregator. I wish Travis would put this in their documentation:
https://www.ctolib.com/article/comments/461
******
Use new Travis image with _JAVA_OPTIONS unset
Per Travis support:
As part of the Trusty image updates we've capped Java memory by setting
the _JAVA_OPTIONS environment variable, which seems to be interfering
with your build. Since you are running in our sudo:required environment
and your build is memory-heavy, I'd suggest unsetting this (it was
mostly aimed at our users running Java inside Docker). For example,
adding "before_install: unset _JAVA_OPTIONS" should do the trick.
******
Kind regards,
Ben.
On 12/09/17 14:21, Ben Caradoc-Davies wrote:
My fix is ineffective. Success depends on how the age of the Travis worker image. The newer workers fail:
Builds on these images succeed:
Build image provisioning date and time
Fri Jul 7 18:52:25 UTC 2017Builds on these images fail:
Build image provisioning date and time
Tue Aug 29 02:50:02 UTC 2017It is a lottery. Affects both GeoTools and GeoServer and all branches.
Kind regards,
Ben.On 12/09/17 13:11, Ben Caradoc-Davies wrote:
Travis started setting _JAVA_OPTIONS, which overrides our Maven memory settings and puts us again at risk of random build failures:
https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/I have removed _JAVA_OPTIONS in .travis.yml on supported branches of GeoTools and GeoServer.
--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
Ben you are stubbornly learning so much about travis; could we write down some care and feeding instructions for these tricks for the developers guide? Or is tarvis too much of a moving target …
On 11 September 2017 at 19:56, Ben Caradoc-Davies <ben@anonymised.com> wrote:
I have applied a new fix to all of the branches. My original fix was likely getting overwritten by some undocumented Travis stage order. Initial tests indicate that the new fix works on the new (August) Travis worker images. It is not needed on the old ones but does no harm.
Of all places I found the fix in some sort of Japanese aggregator. I wish Travis would put this in their documentation:
https://www.ctolib.com/article/comments/461
Use new Travis image with _JAVA_OPTIONS unset
Per Travis support:
As part of the Trusty image updates we’ve capped Java memory by setting
the _JAVA_OPTIONS environment variable, which seems to be interfering
with your build. Since you are running in our sudo:required environment
and your build is memory-heavy, I’d suggest unsetting this (it was
mostly aimed at our users running Java inside Docker). For example,
adding “before_install: unset _JAVA_OPTIONS” should do the trick.
Kind regards,
Ben.On 12/09/17 14:21, Ben Caradoc-Davies wrote:
My fix is ineffective. Success depends on how the age of the Travis worker image. The newer workers fail:
Builds on these images succeed:
Build image provisioning date and time
Fri Jul 7 18:52:25 UTC 2017Builds on these images fail:
Build image provisioning date and time
Tue Aug 29 02:50:02 UTC 2017It is a lottery. Affects both GeoTools and GeoServer and all branches.
Kind regards,
Ben.On 12/09/17 13:11, Ben Caradoc-Davies wrote:
Travis started setting _JAVA_OPTIONS, which overrides our Maven memory settings and puts us again at risk of random build failures:
https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/I have removed _JAVA_OPTIONS in .travis.yml on supported branches of GeoTools and GeoServer.
–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
GeoTools-Devel mailing list
GeoTools-Devel@anonymised.comge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
–
Jody Garnett
So far our Travis problems have been different every time. The Travis documentation is pretty good. The solution is usually to read the logs and use The Google.
Kind regards,
Ben.
On 13/09/17 03:38, Jody Garnett wrote:
Ben you are stubbornly learning so much about travis; could we write down
some care and feeding instructions for these tricks for the developers
guide? Or is tarvis too much of a moving target ...--
Jody GarnettOn 11 September 2017 at 19:56, Ben Caradoc-Davies <ben@anonymised.com> wrote:
I have applied a new fix to all of the branches. My original fix was
likely getting overwritten by some undocumented Travis stage order. Initial
tests indicate that the new fix works on the new (August) Travis worker
images. It is not needed on the old ones but does no harm.Of all places I found the fix in some sort of Japanese aggregator. I wish
Travis would put this in their documentation:https://www.ctolib.com/article/comments/461
******
Use new Travis image with _JAVA_OPTIONS unset
Per Travis support:
As part of the Trusty image updates we've capped Java memory by setting
the _JAVA_OPTIONS environment variable, which seems to be interfering
with your build. Since you are running in our sudo:required environment
and your build is memory-heavy, I'd suggest unsetting this (it was
mostly aimed at our users running Java inside Docker). For example,
adding "before_install: unset _JAVA_OPTIONS" should do the trick.******
Kind regards,
Ben.On 12/09/17 14:21, Ben Caradoc-Davies wrote:
My fix is ineffective. Success depends on how the age of the Travis
worker image. The newer workers fail:Builds on these images succeed:
Build image provisioning date and time
Fri Jul 7 18:52:25 UTC 2017Builds on these images fail:
Build image provisioning date and time
Tue Aug 29 02:50:02 UTC 2017It is a lottery. Affects both GeoTools and GeoServer and all branches.
Kind regards,
Ben.On 12/09/17 13:11, Ben Caradoc-Davies wrote:
Travis started setting _JAVA_OPTIONS, which overrides our Maven memory
settings and puts us again at risk of random build failures:
https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/I have removed _JAVA_OPTIONS in .travis.yml on supported branches of
GeoTools and GeoServer.--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand