Thanks for looking into this Laszlo,
so you think it is a coincidence that it is working when run by travis
but nowhere else?
can I mark this test method with @RandomlyFails for now?
I suppose we could also leave this test on travis for now. What I tried
to do is to aggregate all "build tool" IDE features into one CI job
which is only run if the PR is labeled with Ant, Gradle, Maven, (...).
https://github.com/apache/netbeans/pull/4431
the idea is to let devs/reviewers decide what has to be tested before
integration, based on what is actually influenced by the PR so that CI
can skip some long jobs (short ones are tested since that won't make a
difference anyway resource wise).
https://github.com/apache/netbeans/pull/4431
best regards,
michael
On 31.07.22 03:49, Laszlo Kishalmi wrote:
It seem I have my own history with that test.
See: https://github.com/apache/netbeans/pull/3298
The discussion in the PR mostly on the first disabled testcase, as the
ScriptEngine it was not correctly initialized on Java 11. That got
solved.
The other TC I put on the Ignore list is a wish to be working case of
Gradle project loading infrastructure. I do not know if Svata managet
to get that work in a branch or not, but I have not seen it working.
Some background info:
NetBeans Gradle projects tracks the quality of information it is
having on the actual Gradle project. Information is like classparhs,
dependencies, etc.
There are 3 main qualities (the actual implementation is more granular
though):
FALLBACK - The information is guessed by heuristics, Gradle was not
asked to fetch it.
FULL - Gradle returned the full information, NetBeans shall know
everything it needs.
EVALUATED - We turned to Gradle at least once, but the last attempt
had issues, so we shall live with the last information we have, but
shall try to retrieve the FULL information whenever we have the chance.
So when NetBeans sees a Gradle project, for performance reasons it
loads the FALLBACK information using heuristics.
However imagine the situation, that once upon a time we have opened a
project, and that got inspected by Gradle, so NetBeans has the project
information in disk cache.
Now we close the project, maybe NetBeans as well.
Next time you have a project open, which uses some classes from an
un-opened Gradle project. Just clicking on the Go to source, should
gisplay the file from the closed project, but it is marked all read,
as the project just have the FALLBACK information on the classpath.
However in that case we have the project information easily accessible
in the disk cache, which if valid could hold the FULL information,
even with invalid cache loading that info (EVALUATED) could be better
than the heuristic. (There are other use cases where this would be
useful as well)
That is the behavior this failing TestCase is for. Unfortunately right
now the Gradle plugin does not work that way.
On 7/30/22 04:28, Michael Bien wrote:
Hi,
I am having trouble to get those tests green while working on moving
more jobs from travis to github. They appear to work "ok" on travis
but fail both locally and on github.
Since the tests are marked unreliable (exile job) with a retry
command, I would like to exclude that I am just hitting some weird
timing issue here with tests which only work on travis when all stars
align.
Do they work for anyone locally?
Travis runs them with this line on JDK 8:
OPTS="-Dmetabuild.jsonurl=https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/master/meta/netbeansrelease.json
-Dcluster.config=java -Djavac.compilerargs=-nowarn
-Dbuild.compiler.deprecation=false
-Dtest-unit-sys-prop.ignore.random.failures=true"
ant $OPTS -f java/gradle.java test
ClassPathProviderImplTest.testCompilePreTrusted is failing my my
case. It fails the exact same way when simply started from NetBeans,
in a shell or on github. The log has lots of exceptions and "can't
load module" warnings, but I went so far to diff the travis log
(without -quiet) with the local log and they exist in both cases at
the same places.
best regards,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
