I have a build that used to work 0, but is now broken 1. It seems to be related to installing oraclejdk8:
$ ~/bin/install-jdk.sh --target “/home/travis/oraclejdk8” --workspace “/home/travis/.cache/install-jdk” --feature “8” --license “BCL”
install-jdk.sh 2019-05-02
Expected feature release number in range of 9 to 14, but got: 8
The command “~/bin/install-jdk.sh --target “/home/travis/oraclejdk8” --workspace “/home/travis/.cache/install-jdk” --feature “8” --license “BCL”” failed and exited with 3 during .
I haven’t changed the travis.yml since creating this project. Builds have never failed before installing oracle jdk 8, and now they are, yet I haven’t changed anything.
Furthermore, I have many other projects (e.g. 2, 3) that also use oraclejdk8 and build without error.
Can anyone offer insight as to what is going on? For example, why is it the project at 0 the only one to be affected (as far as I can tell)? Why is the build breaking even though I haven’t made changes to the build environment?
I’m not sure Marten! This is all very confusing. How could Travis break my Java 8 builds without providing some kind of notice or additional information?
It looks like my last successful build (0) was using ‘Build dist: trusty’, and the failing build (1) is using ‘Build dist: xenial’.
I’ve met the same problem those days, after tens of trials I found that this error is caused by the Ubuntu distribution used by task. For the one you stated as “working”, it’s running on trusty, and the errored one was running on xenial.
TO FIX THIS, add the following code to your .travis.yml file,
dist: trusty
To manually appoint the Ubuntu distribution version.
Thanks for all the replies, adding “dist: trusty” fixed my issue.
the question is: why did my build environment change under my feet? Kind of defeats the purpose if your build environment changes underneath of you without you knowing.
I have many many repositories that use Oracle JDK 8, and only a handful have been affected by this issue: as if some of my environments have been migrated to Xenial, while some have not.
After further analysis, there seems to be some discrepancy between the machine instances of last working and first non-working build: with ‘dist’ parameter being unspecified, both reference dists are tagged as ‘bionic’, but the working one reports Ubuntu 12.04, while the non-working one reports Ubuntu 18.04 (this can be seen in ‘Worker information’ in the build log)
Looks like change of default distro from trusty to xenial got rolled out gradually, and if you didn’t specify dist, your default dist changed when it got rolled out, from trusty to something else, which made existing config stop working, but telling it to use trusty again made it work again?
Doens’t explain @pgp saying he saw things claiming to be xenial with different version numbers, that could be a different bug?