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
Related
I have a solution with many projects, and we are migrating to .NET SDK style projects, but for now we have a mix of .NET framework style projects and .NET SDK style projects.
We are also migrating to GitHub actions, and this solution was building without errors previously, but the restore action started failing when dotnet was updated from 6.0.300 to 6.0.400 (update: I tried targeting 6.0.300 specifically in the setup-dotnet action, but it's throwing the same errors, so I'm not sure what changed to cause it to fail like this when it was working before.)
I updated our local action server to 6.0.400, and when I run the command dotnet restore ./path/to/solution.sln it is restoring the NuGet packages for just the .NET SDK style projects as expected.
dotnet is installed with this GitHub action
- name: Setup .NET
uses: actions/setup-dotnet#v2
with:
dotnet-version: 6.0.x
and restore is being called with this GitHub action
- name: Restore dependencies
run: dotnet restore ${{env.SOLUTION_FILE_PATH}}
and when dotnet restore is being run from the GitHub action, I am getting the following error error MSB4057: The target "Restore" does not exist in the project. for all of the .NET SDK style projects. It's as if it's trying to restore NuGet packages using the older .NET Framework style NuGet packages. This is very different than what I've seen before and is unexpected. I have a separate action for calling nuget restore ./path/to/solution.sln for restoring packages for the .NET framework style projects, and I'm expecting dotnet restore to only restore the .NET SDK style projects.
Has anyone else run into similar problems with dotnet 6.0.400? Are there better options for restoring NuGet packages in GitHub actions?
I'm not really sure where to look next because running the command line commands locally work exactly how I would expect them to, and it only behaves oddly when getting called from GitHub actions.
Update:
I've been able to reproduce the failure locally by running the dotnet version that is being installed locally as part of actions/setup-dotnet#v2
If I run dotnet restore ... from the global install location C:\Program Files\dotnet\dotnet.exe then I get the following output which is what I expect
Determining projects to restore...
Restored C:\actions-runner\_work\MySolution\MySolution\src\FirstSdkProject\FirstSdkProject.csproj (in 335 ms).
Restored C:\actions-runner\_work\MySolution\MySolution\src\SecondSdkProject\SecondSdkProject.csproj (
in 357 ms).
If I restore from the locally installed dotnet at C:\Users\MyUser\AppData\Local\Microsoft\dotnet then I get the unexpected output that I'm getting in the GitHub action
Determining projects to restore...
Determining projects to restore...
C:\actions-runner\_work\MySolution\MySolution\src\FirstSdkProject\FirstSdkProject.csproj : error MSB4057: The target "Restore" does not exist in the project.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
C:\actions-runner\_work\MySolution\MySolution\src\SecondSdkProject\SecondSdkProject.csproj : error MSB4057: The target "Restore" does not exist in the project.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Comparing the information on dotnet.exe, they are the exact same version of dotnet and using a file compare program they are binary the same, and the folders they are in are seemingly the same as well with only a few minor differences. Why would running restore have two very different outcomes just running from different locations?
One of the main differences between a .NET Framework project and a .NET SDK project is how NuGet package references are managed. With .NET Framework projects, NuGet references are managed in packages.config. To build and restore including packages.config references you need the following
msbuild -t:build -restore -p:RestorePackagesConfig=true ./path/to/solution.sln
If you don't have mixed projects and they all follow the .NET SDK csproj format, then you won't have any packages.config references and you can build and restore with this.
msbuild -t:build -restore ./path/to/solution.sln
The option RestorePackagesConfig is only available on msbuild 16.5+ https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#restoring-packagereference-and-packagesconfig-projects-with-msbuild
I am installing Hudson CI in Windows Server 2008. I have some issues when build are failure and these message appear..
Skipping watched dependency update for build
How to solve?
This message appears every time even when the builds are successful. I think the message is debug statement in the code so appears in the log.
I have a job in Hudson server A which builds an artifact and deploys it to Nexus. I have another job in a completely separate Hudson server B which needs to download the artifact and deploy it. This job is normally run manually, and the person running it needs to indicate which version of the artifact to deploy - they may not always want to deploy the latest version (e.g. to roll back to a previous known good version).
Currently, I achieve this by using a parameterized build, and require the user to pass in the artifact version number; the job then uses the Execute shell build step to run wget on a URL constructed using the parameter. This is error prone.
Ideally I'd like a plugin that lets the user browse the artifact versions in the Nexus repository and pick and choose the one to deploy, but I'm open to other suggestions. A plugin that also handles the download would be nice, but I can live without it as long as I can still get a string that I can use in shell commands.
I've looked through the available Hudson & Jenkins plugins around Maven style artifact repositories, but they all seem more concerned with pushing artifacts into repos rather than getting them back down.
I'm using Hudson's "Copy Artifact" in other jobs, to get artifacts from other Hudson jobs on the same server, but this doesn't work across different Hudson servers, which is why I've turned to Nexus (which we're already using anyway).
Does anyone have any suggestions?
I recommend using rundeck to execute your deployments.
There is a rundeck plugin for Nexus that enables rundeck to display a pull down menu of available versions in Nexus.
There is a rundeck plugin for Jenkins that can be used to invoke deployments using rundeck and kick-off post deployment jobs (like integration testing) inn Jenkins.
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.
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.