This message was deleted.
# community-support
s
This message was deleted.
a
It looks like that. Our CI jobs are also failing with these errors šŸ˜•
r
Womp womp. Do you know of any place where we can follow along on the status of this?
Follow up question if you don’t mind: We run our CI builds in containers based on
eclipse-temurin
images, and adoptium is our prioritized toolchain vendor. That JDK shoudl already be in the container. Do you know why the resolver is reaching out to the DiscoAPI at all in the first place? T
v
Is it in a place where toolchains are searched for? Did you disable searching?
r
Hey @Vampire great questions.
Is t in a place where toolchains are searched for?
That’s a great question. When you say ā€œitā€, do you mean the installed JDK? If so, then I would assume yes since the JDK is in the default
$JAVA_HOME
directory.
Did you disable searching?
Can you elaborate on this one? Did I disable what searching for what, specifically? For some additional context, we apply the foojay plugin, but we don’t do any special configuration with it currently.
Ah, looking at the Gradle docs, no, we’re disabling auto-detection: https://docs.gradle.org/current/userguide/toolchains.html#sub:disable_auto_detect
We generally set the toolchain version to Java 11 for all builds, and then those builds are conducted in an
eclipse-temurin:11
based container. We’re also running Gradle 7.6.1, but starting the upgrade to 8.x now.
v
Yeah, well, if you disable auto-detection, it can of course not be auto-detected. šŸ˜„
r
Ahhh that was just an unfortunate typo, I meant to say ā€œno, we’re not disabling auto-detection.
v
šŸ˜„
šŸ¤¦ā€ā™‚ļø 1
Then maybe check what the
javaToolchains
task says
If that Java you are "missing" is the one running Gradle, it should actually also be found, no matter where it is installed. If you run Gradle with a different toolchain, then it has to be in one of the location searched by the algorithm, or configured by you
r
Added a run of the javaToolchains task to a failing CI build, and i’m seeing this: [2023-09-08T161938Z] > Task :javaToolchains [2023-09-08T161938Z] [2023-09-08T161938Z] + Options [2023-09-08T161938Z] | Auto-detection: Enabled [2023-09-08T161938Z] | Auto-download: Enabled [2023-09-08T161938Z] [2023-09-08T161938Z] + Eclipse Temurin JDK 11.0.19+7 [2023-09-08T161938Z] | Location: /opt/java/openjdk [2023-09-08T161938Z] | Language Version: 11 [2023-09-08T161938Z] | Vendor: Eclipse Temurin [2023-09-08T161938Z] | Architecture: amd64 [2023-09-08T161938Z] | Is JDK: true [2023-09-08T161938Z] | Detected by: Current JVM This all seems fine to me and as expected. We don’t manually set a vendor in our in our toolchain closures, just a major language version of 11.
I’m sorry if I’m completely missing the point here. I haven’t had to debug this before, so if I’m looking in the wrong place, I’m happy to be corrected.
v
No, seems fine. With that, it should not need to auto-provision if you only use 11 toolchain. Maybe you can see something in the
--info
or
--debug
log, for example what it tries to query from disco?
r
Well, the debug log gave us the request, but it doesn’t seem to give a lot of insight as to why this request is being made at all:
Copy code
[2023-09-08T17:04:18Z] 2023-09-08T16:53:47.157+0000 [DEBUG] [sun.net.www.protocol.http.HttpURLConnection] sun.net.www.MessageHeader@5b1b38e46 pairs: {GET /disco/v3.0/distributions?include_versions=true&include_synonyms=true HTTP/1.1: null}{Content-Type: application/json}{User-Agent: Java/11.0.19}{Host: <http://api.foojay.io|api.foojay.io>}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: close}
[2023-09-08T17:04:18Z] 2023-09-08T16:53:47.225+0000 [DEBUG] [sun.net.www.protocol.http.HttpURLConnection] sun.net.www.MessageHeader@11385d55 pairs: {null: HTTP/1.1 503 Service Temporarily Unavailable}{Date: Fri, 08 Sep 2023 16:53:47 GMT}{Content-Type: text/html}{Content-Length: 190}{Connection: close}
v
Well, was worth a try. You can disable auto-provision of course. Maybe you should and see what happens. If it succeeds, then you should maybe open a bug report. If it fails, maybe the failure contains more information.