-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ci] add jdks to test matrix #1131
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1131 +/- ##
==========================================
- Coverage 87.31% 87.22% -0.09%
==========================================
Files 113 113
Lines 10281 10281
Branches 4065 4065
==========================================
- Hits 8977 8968 -9
- Misses 707 718 +11
+ Partials 597 595 -2
|
@Thrameos I could use some help to figure out why the ivy deps are not found for some jobs - thank you :) |
Sure. Though there may be other ways to skin that cat like calling it once and shipping the artifacts arounf. Been a while since I looked at it. |
I looked through the logs. It is not an ivy failure. The first step of the process is to create the artifact deps which are then used for all builds. Thus if the failure was with ivy it would have failed in the first stage of the build and every build after it would have failed as well. The fact that some worked and some did not indicates that the dependencies are there but they didn't work for every build. So lets look at the possibilities:
The jars being pulled are too new for 8 so most likely it is JDK 52.0 version conflict (causing one type of fail) and something has changed in 17 that is not allowing the driver to load in 17. The last one is more of a mystery as I rarely get things to fail forward unless they are hitting the ByteBuffer symbol conflict bug. To diagnose I will have to install the same versions of JDK and the jars and try to get them to manually load in hopes of forcing an error. The JDK silently ignores any jars that fail to load from the classpath, so manual loading is required to get diagnostics. I will need to investigate further. Safest fix for the JDK 8 is to add an option to skip the dbc tests for those builds. JDK is dead as a doornail at this point and it is hard to ensure that 3rd party jars will work with it going forward. 17 needs investigation. |
thanks for looking into it. I'll be on vacation next week. So I wont be available that time. Do you intend to push the release in the next two weeks? |
I was aiming for the end of April but I can push it back. We have a lot of things left to resolve so the time may be needed anyway. |
Sounds good. I have another PR that will need to go out shortly and having a working test bench will be required. Apparently, Python broke parts of the object system again in 3.13.
|
Right, I'm gonna finish this one soon. |
Added a mixture of JDK versions to our testing matrix. Version 8, 11, and 17 are being checked.
TODOs: