I'm using NetBeans and GlassFish 3.0.1 to create an EJB3 application. I have written a few Unit Tests, which get run via JUnit and make use of the embedded GlassFish. Whenever I run these tests on my development machine (so from within NetBeans), it's all good.
Now I would like to let Hudson do those tests. At the moment it is failing with lookup failure on a resource (in this case the datasource to a JPA persistance unit):
[junit] SEVERE: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method
[junit] java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'mvs_devel' in SerialContext
After searching around and trying to learn about this, I believe it is related to the embedded GlassFish not having been configured with resources. In other words it's missing a domain.xml file. Right?
Two questions:
Why does it work with NetBeans on my dev box? What magic does NetBeans do in the background?
How should I provide the file? Where does the embedded GlassFish on the Hudson-box expect it?
Hudson is using the same Ant build-scripts (created by NetBeans).
I've read this post about instanceRoot and the EmbeddedFileSystemBuilder, but I don't understand enough of that. Is this needed for every TestCase (Emb. GF gets started/stopped for each bean-under-test)? Is this part of EJBContainer.createEJBContainer()? Again, why is it not necessary to do this when running tests on NetBeans?
Update
Following Peter's advice I can confirm: when running ant on a freshly checked out copy of the code, with the same properties as hudson is configured, the tests get executed!
10-1 it is a classpath issue as IDE's tend to swap paths in and out depending if you run normally or unittests.
Try running the tests on a commandline from a freshly checked out version from your SCM. Chances are you'll have the same error. Debugging on your local machine is a lot easier than on a remote machine.
When it builds reliably on the command line (in a separate directory) then it is time to move to hudson.
Related
I set up a Jenkins job to run some integration tests. After testing finishes, Jenkins should look for test report in settings. However, it gives following error:
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
java.lang.NoClassDefFoundError: hudson/tasks/junit/JUnitParser$ParseResultCallable
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)
at hudson.model.Run.execute(Run.java:1779)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Finished: FAILURE
Here is my Publish Junit result setting:
I checked the path for those xml files in workspace, they do exist. I'm not sure what could be wrong. My JUnit Plugin version is 1.5.
You have a version mismatch between the JUnit version in your build and the version that is loaded into Jenkins. https://issues.jenkins-ci.org/browse/JENKINS-24946 may provide some insight, but in general, you need to be very careful that the versions are compatible.
I think there is some configuration issue, somewhere in configuration it's not updating with latest version.
At some point of time you have to work with latest version.
Instead of downgrading just create a new branch of your project.
I created new branch of my project then build went smoothly although still it is failing with older branch. So better you work with latest version of JUNIt by creating new branch, jenkin will pick it automatically.
Also Wiping out Current Workspace may help
One of our test classes extends RemoteBaseTest but Jacoco ignores it completely.
How can I make Jacoco work with Sling Integration Testing?
For Unit Tests everything works as expected.
We are using Adobe CQ 5.6.1.
I see that this issue has been resolved: sling-issue-tracker-2810
but unsure how to implement it - is it even included in the latest CQ-Version yet?
If not how do I manually add it?
I don't know what RemoteBaseTest is but I assume you are running a JUnit "proxy" test which talks to the Sling JUnit server-side tests subsystem and causes the actual tests to run on your CQ server.
If that's correct, the actual test code doesn't run in the client JVM that's running RemoteBaseTest, it runs in the server JVM that's running CQ. So it's on the server JVM that you need to setup Jacoco to collect coverage data.
If you're running some tests on the client JVM (like common JUnit tests) and some on the server JVM via the Sling testing tools, Jacoco has functions to merge coverage data coming from different JVMs. We have this as a work in progress in https://issues.apache.org/jira/browse/SLING-1803 , which is not fully integrated in Sling yet but should be adaptable to any version of CQ.
I installed Jenkins on my build machine and in the Jenkins config checked the box to run sonar analysis on my maven based project. It works but if I look at the log my entire project is built twice. Once from maven and once for sonar (still using maven). Any idea what I am doing wrong here?
Sonar analysis is performed through a maven plugin. So, whenever you start a sonar analysis, maven will run through all phases that come before the sonar phase, meaning that it will also run the compile and the test phase.
This means, if you want to do a Sonar analysis, you can make a Free-Style Job in Jenkins, configure no Build Step, and only activate the Sonar button. That should work, and should only build your code project once.
I have a bunch of Maven projects building in Hudson with Sonar sitting in the side-lines. Sonar gives me Sonar stats, FindBugs stats, and code-coverage.
I've noticed that regardless of if I use Sonar or if I use EMMA via Maven directly, the entire build cycle runs twice. This includes init (which in my case, reinitializes the database -- expensive) and unit tests (a few hundred -- also expensive).
How can I prevent this? I did a lot of reading, and it seems like this is due to the design of code-coverage plugins -- to keep uninstrumented classes separated from instrumented ones.
I've tried configurations like:
Maven runs: deploy, EMMA
Maven runs: deploy; deploy to Sonar on completion
The sonar documentation recommends running the sonar plugin in 2 stages:-
mvn clean install -Dtest=false -DfailIfNoTests=false
mvn sonar:sonar
The tests are bypassed in the first phase and run implicitly in the second stage.
A one line alternative is to run the following command:-
mvn clean install sonar:sonar -Dmaven.test.failure.ignore=true
but this will run the tests twice - as you have found.
To add to #Strawberry's answer, you could reuse the unit test reports instead of running them again. Refer to the section Reuse existing unit test reports in the sonar documentation
Once this is done, you can configure the following in Hudson
clean deploy sonar:sonar
I am setting up a new Hudson task (on WinXP) for a project which generates javascript files, and performs xslt transformations as part of the build process.
The ant build is failing on the XSL transformations when run from Hudson, but works fine when the same build on the same codebase (ie in Hudson's workspace) is run from the command line.
The failure message is:
line 208: Variable 'screen' is multiply defined in the same scope.
I have tried configuring Hudson to use both ant directly and to use a batch script - both fail in Hudson.
I have tried in Firefox, IE6 and Chrome and have seen the same issue.
Can anyone suggest how we can workaround this problem with Hudson?
Problem solved.
Our build is actually dependent on jdk 1.4.2, and Hudson appears to run using 1.6. When I set Hudson to run as a service, it ran as my local user, which meant that it picked up the 1.4.2 JAVA_HOME environment variable - and therefore worked.
I guess another possible solution is to configure Hudson to use 1.4.2 by default.
I would assume this is not an issue with Hudson directly, as it is with the build script and/or the environment itself.
Is your build script relying on certain environment variables being defined, or worse, the job running from within a certain directory structure (i.e. it works if it's run from under /home/mash/blah but not from under another directory like /tmp)? Is the build script making reference to external files by relative paths?
These are the things I would look into. For environment variables, you can tell Hudson to pass these into Ant. For the other issues, you probably want to change your build script. Check the console output provided by Hudson, and maybe set Ant to print verbose/debug messages to get a better idea about the environment/filepaths.