Jenkins is not a morning person.
35 views
Skip to first unread message
Eric Molitor
Oct 8, 2012, 7:01:17 AM10/8/12
to scala-...@googlegroups.com
Hello Everyone,
A few common variations of JCompiler unit test failures plague the automated Juno builds. However I'm not able to reproduce the issues on any of my build machines and manually initiated builds via Jenkins always seem to succeed. I've only become frustrated enough to start looking into the issue this morning. I'm wondering if there is a sequencing/timing issue with the build and its dependencies, if Jenkins is not a morning person or if Jenkins just hates me.
There are many other examples in the previous builds. I'll starting poking away at this later today but any hints are greatly appreciated.
- Eric
iulian dragos
Oct 8, 2012, 8:49:47 AM10/8/12
to scala-...@googlegroups.com
On Mon, Oct 8, 2012 at 1:01 PM, Eric Molitor <emol...@molitor.org> wrote:
>
> Hello Everyone,
>
> A few common variations of JCompiler unit test failures plague the automated Juno builds. However I'm not able to reproduce the issues on any of my build machines and manually initiated builds via Jenkins always seem to succeed. I've only become frustrated enough to start looking into the issue this morning. I'm wondering if there is a sequencing/timing issue with the build and its dependencies, if Jenkins is not a morning person or if Jenkins just hates me.
Hi Eric,
>
> Hello Everyone,
>
> A few common variations of JCompiler unit test failures plague the automated Juno builds. However I'm not able to reproduce the issues on any of my build machines and manually initiated builds via Jenkins always seem to succeed. I've only become frustrated enough to start looking into the issue this morning. I'm wondering if there is a sequencing/timing issue with the build and its dependencies, if Jenkins is not a morning person or if Jenkins just hates me.
this is a thorny issue. I recently added more logging trying to get to
the bottom of this, but like you, I couldn't reproduce it locally, nor
by triggering builds.
It's for sure a race condition.. but I don't know where it originates.
The test checks that we suppress some errors coming from the Java
compiler (for a Java class extending a Scala class that extends a
trait with concrete members, Eclipse javac will report those trait
methods as un-implemented). We do that by weaving in the Java method
resolver. Code is here:
https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/src/scala/tools/eclipse/jcompiler/ScalaMethodVerifierProvider.scala
In the runs that fail, AFAICT, the code is not even invoked. So either
weaving failed, or some other thing prevents the method verifier from
running correctly. If you look for `entered isConcreteMethod` in the
log, you should see where/how things happen.
Please let us know if you find anything, as we are also trying to nail it down.
iulian
>
>
> https://jenkins.scala-ide.org:8496/jenkins/view/Scala%20IDE%202.1%20for%20Juno/job/scala-ide-juno-nightly-master-29/381/testReport/scala.tools.eclipse.jcompiler/AbstractMethodVerifierTest/javaClassExtendingScalaClassWithConcreteMethodsInSuperTrait_NoErrorIsReportedInJavaEditor_t1000594_pos/
> https://jenkins.scala-ide.org:8496/jenkins/view/Scala%20IDE%202.1%20for%20Juno/job/scala-ide-juno-nightly-master-29/383/testReport/scala.tools.eclipse.jcompiler/AbstractMethodVerifierTest/simplifiedExampleFromAkkaSources_ThatWasCausingWrongErrorsToBeReportedInTheJavaEditor_t1000752_2/
>
> There are many other examples in the previous builds. I'll starting poking away at this later today but any hints are greatly appreciated.
>
> - Eric
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Reply all
Reply to author
Forward
0 new messages