-
Notifications
You must be signed in to change notification settings - Fork 866
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
Prepare CI for NB 22 and bump minimum JDK requirement to 17 #7019
Conversation
well. some jobs did in fact not fail :) |
d428701
to
c1dbdbd
Compare
fascinating. Out of almost 3k Lines 67 to 69 in 805b153
|
I think that we are seeing a scanning effect here. Even for JS this is bogus: netbeans/webcommon/javascript2.editor/test/unit/data/testfiles/completion/issue215777.js Lines 1 to 2 in 805b153
I assume that the indexer picks up the Patch (wrapped in ZIP because GH in its infitite wisdom rejects my patch file...) 0001-Stabilize-JS-Test-testIssue215777.zip I was able to reproduce the problem locally and this fixed it for me. |
51fdf0b
to
552f4f8
Compare
thanks @matthiasblaesing, I added your commit - everything should be green now. The cause for this might be that the method order is slightly different. |
if (!"natural".equals(orderS)) { // NOI18N | ||
try { | ||
// TODO: ClassLoader fields can not be accessed via reflection on JDK 12+ | ||
// see jdk.internal.reflect.Reflection#fieldFilterMap | ||
// this won't work | ||
Field classesF = ClassLoader.class.getDeclaredField("classes"); // NOI18N |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
luckily nothing seems to be using test case ordering: https://github.com/search?q=repo%3Aapache%2Fnetbeans%20NbTestCase.order&type=code
so I haven't bothered to fix it. (I am also not sure if there is an easy fix, this might require instrumentation, a custom CL or some hooks into junit)
/**Sets a source level for all Java files used in this test. | ||
* | ||
* @param sourceLevel the source level to use while parsing Java files | ||
* @return itself | ||
*/ | ||
public HintTest sourceLevel(int sourceLevel) { | ||
assertTrue(sourceLevel >= 8); | ||
return this.sourceLevel(Integer.toString(sourceLevel)); | ||
} | ||
|
||
/**Sets a source level for all Java files used in this test. | ||
* | ||
* @param sourceLevel the source level to use while parsing Java files | ||
* @return itself | ||
*/ | ||
public HintTest sourceLevel(String sourceLevel) { | ||
try { | ||
int valid = sourceLevel.startsWith("1.") ? Integer.parseInt(sourceLevel.substring(2)) : Integer.parseInt(sourceLevel); | ||
} catch (NumberFormatException ex) { | ||
throw new IllegalArgumentException(ex); | ||
} | ||
this.sourceLevel = sourceLevel; | ||
return this; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some tests used SourceVersion.latest().name()
as source level which would be the full enum name. This would be quietly ignored and cause weird issues.
The expected format is now enforced and the tests were fixed which used it wrong.
+ " if (s instanceof Person(String name, int s1) p) {\n" | ||
+ " if (s instanceof Person(String name, int s1)) {\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lahodaj i think the tests were wrong? This doesn't seem to be a valid syntax when it also includes the field name.
Another side effect of this PR is that more tests are now active.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sane to me. Thank you.
going to squash soon and make this ready to merge. Plan is to merge short after the next delivery->master sync. |
NB 22 will be released when JDK 22 is already out, I am wondering if we should: a) change matrix to I am slightly in favor of a) even though it wastes a bit more resources, since one release from now the delta between 21 and current will grow, then we will have to run the a) variant anyway. |
@mbien I'm also in favour of a) because that is the approach agreed in the minimum JDK support vote. Of course, if there are tests that consume a lot of resources, we might consider something different on a case-by-case basis. |
552f4f8
to
f2079bc
Compare
merging once green assuming nothing else shows up |
i think this will cause too many failures atm. The commit validation matrix would produce 5 runs, combined with the java debugger job at 3 runs we would have to play whack-a-mole a bit too much, I already restarted twice and it is failing again.
I found a hack to exclude matrix elements conditionally by the fake ternary operator of the expression language. this opens more options, lets try to find a compromise.
added retry script to CV step and even more fixed tests so that hints tests can run on 21 |
27a8fdf
to
596ba28
Compare
- add 22-ea to the matrix - exclude some matrix elements for master, this frees more for label-controlled PRs without worsening the whack-a-mole factor bump action versions to fix deprecation warnings: - actions/cache to v4 - actions/setup-java to v4 - actions/setup-node to v4 add retry script to - ide/libs.git - ide/notifications - commit-validation run some tests on JDK 11 which don't work on 17+ tests which require a js script engine: - many platform/(api.)templates tests require js - profiler/profiler.oql OQL does also require js, - BindingsNGTest in webcommon/api.knockout and - TemplatesMimeTypeTest in platform/openide.loaders too other reasons - platform/core.network fails on 17+
fix CanProxyToLocalhostTest: Proxy#toString changed slightly fix JavaCompletionTask121FeaturesTest: add Record to test data fix ConvertToRecordPatternTest and ConvertToNestedRecordPatternTest - enforce parsable source level for hint tests - update record patern syntax in tests fix BroadCatchBlockTest: use stable/jdk-independent test files - jdk keeps removing throws declarations from methods, esp when they extend RuntimeException -> lets make our own test Klasses Stabilize JS Test testIssue215777 by Matthias - split golden files into two NbTestCase method ordering is always using "natural" order - ClassLoader fields can not be accessed via reflection on JDK 12+ - test method ordering options are not used anywhere atm - disable tests Co-authored-by: Matthias Bläsing <mblaesing@doppel-helix.eu>
596ba28
to
a0109cc
Compare
all green, merging |
note: the graal job is still using an JDK 11 equivalent since #6369, this PR does not change this. However, this should unblock future graal updates, see #7013 (comment)