Fix LSP/Micronaut tests + don't ignore exception in gradle spi#6673
Conversation
- remove snapshot repos - MicronautGradleArtifactsImplTest: assert project build has no problems found.
so that gradle can download the distribution without SSL handshake failure. Remove ASAP. TemplateOperation: Don't ignore gradle exceptions.
| static { | ||
| // TODO remove ASAP from MicronautGradleArtifactsImplTest and ProjectViewTest | ||
| // investigate "javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure" | ||
| // during gradle download "at org.netbeans.modules.gradle.spi.newproject.TemplateOperation$InitStep.execute(TemplateOperation.java:317)" | ||
| // this looks like a misconfigured webserver to me | ||
| System.setProperty("https.protocols", "TLSv1.2"); | ||
| } |
There was a problem hiding this comment.
webserver does not support TLS 1.3:
https://www.ssllabs.com/ssltest/analyze.html?d=services.gradle.org&s=2606%3a4700%3a0%3a0%3a0%3a0%3a6811%3a8125
but it appears as if the download tries it anyway and that is when the failure happens or there is some other bug in protocol negotiations
There was a problem hiding this comment.
It's strange because even java.gradle module contains wrapper instructions to download gradle 7.5 .... do those tests pass ?
There was a problem hiding this comment.
you can see what tests pass here for example:
https://github.com/apache/netbeans/actions/runs/6789437471
There was a problem hiding this comment.
Interesting. MN tests fail me even locally, while Gradle Java test did download gradle 7.5 distribution even though it has the same server in its wrapper.properties (https://services.gradle.org/distributions/gradle-7.5-bin.zip vs. https://services.gradle.org/distributions/gradle-7.6.2-bin.zip).
There was a problem hiding this comment.
yeah its easily reproducible locally. All I had to do is to clear my .gradle folder (I kept the properties file).
There was a problem hiding this comment.
someone pressed the wrong button in the admin console, even my raspi runs better cipher suites, more than half of them on the gradle server use weak key length / algo combinations
There was a problem hiding this comment.
BTW I wireshark-captured the communication; what's funny is that the client (that is my laptop) reports different set of available cipher suites when connecting for gradle 7.5 download (from java.gradle test suite) than when connecting for gradle 7.6.2 (micronaut test suite).
There was a problem hiding this comment.
well the cert is from cloudflare, the rest of the infra probably too (I haven't checked). So all machines are going to be virtual, load balanced and ddos mitigated. So file A can be on the other side of the world than file B.
Do I interpret this as go-ahead with merge?
There was a problem hiding this comment.
Probably yes. I'd suggest to document the requirement to set that property in gradle's arch.xml or somewhere, since any testsuite that uses gradle project as test data may suffer from the same mystery.
Re. cipher suites: according to the capture, the client (that is: our CI machine) started the handshake by offering different set of capabilities - there was no message whatsoever from the server before that (all payloads before Client Hello were zero length). The certificate is sent after server hello (which happens after client hello).
So the difference was IMHO not caused by potentially load-balanced server sending something.
There was a problem hiding this comment.
I am not planning to document this since this is a hack and has to be removed asap.
We can't lock the test JVM to outdated TLS modes.
edit: filed an issue #6680
neilcsmith-net
left a comment
There was a problem hiding this comment.
Well, tests are green! I'll merge tomorrow and then sync direct to master unless anyone says to hold off before then.
Looks like we'll have a 20-rc4 so be good to have tests clean for anything coming in to delivery. Thanks!
|
Thanks for fixing this, Michael! |
targets delivery
This attempts to fix the failing LSP and Micronaut jobs.
This took a while to find due to several reasons (not going to write everything down here), two of them being that a key gradle exception was swallowed deep in setup code and that this wasn't reproducible locally unless the
.gradlecache was cleared - which lead me to the wrong paths during investigation. (also the tests are difficult to work with since they throw exceptions even when green!)Initially it wasn't even clear that this was a gradle issue, but after trying other JDK vendors, reverting commits until the last green master build and double checking that nothing else changed in the CI environment, this was the only path left.
tested locally. lets see if CI is ok with it
swallowed Exception during test data setup (gradle project used as test for IDE features):
Details