The problem:
Bamboo executes old unit tests that don't exist my current develop branch which causes a build error.
The situation that causes this problem:
After a big refactoring process of my maven java project, where I basically moved, modified and renamed every file, I committed my changes to my remote repository.
That triggered my bamboo build plan, to start the build process.
The git code checkout seems to work, but the next step, running the unit tests, fails!
Looking in the log file I see that an old, no more existing java Unit test class gets executed and of course fails because of NullPointerExceptions.
Things I tried to fix this problem
A. Remove caches in the Administration section
I went to Bamboo->Administration->Repository Settings and selected
the cache of my project and deleted it.
I started the build plan again
BUILD ERROR ! Same problem
B. Delete the cache directory in the file system
Start a RDP session on the bamboo server
stop bamboo
go to D:\bamboo-home_64\xml-data\build-dir_git-repositories-cache
delete all files in this folder
start bamboo
start the build plan again
BUILD ERROR! same problem
Meta info
bamboo version: 6.1.0 build 60103 - 18 Jul 17
I don't know what I can do to fix this..
There's Clean working directory task. Add it as first task to your Job and see if it solves the issue.
Related
Until recently everything worked fine with our build process in Jenkins. We got a quite big project with many modules and a complicated dependency structure.
Suddenly, the build fails with error messages like the following:
Failed to execute goal certain-plugin:109:certainEar(certainEar)
on project app: certain plugin: Can't explode ear file
'app-SNAPSHOT.ear': Error, directory can't be deleted
The maven command that gets executed in the build pipeline and results in the error message is the following:
mvn -B -U package -DskipTests
A temporary workaround is manually deleting the affected directory. Previously I had a similar problem with the deletion of an ear, there it was possible to exclude the affected ear from this build step as it was not required there. Afterwards I got the error message mentioned above.
Now I found a (kind of) final solution: Adding clean to the targets of the maven command:
mvn -B -U clean package -DskipTests
Now the building step works fine. But why the heck does this happen? Do you have any hints what could lead to this behavior? I'm quite clueless to say the least.
Somehow this could have something to do with the extraction of an ear out of our big app ear. Shortly after we finished this and merged it into our master branch those errors began to arise. As I was not involved in this work it's hard to track down what happened there exactly and what could lead to this behavior. In parallel I will investigate what the colleagues did there. Hints from you what the reasons could be will certainly help to track this down.
I found nothing similar to this error messages online that helped me in any way.
Your solution "mvn clean" indicates me that your job is executing on a jenkins workspace that contains the execution of the previous job. I would recommend to always start your job by clearing what's in the workspace. In freestyle job, under section Source Code Management you can add the behavior
Wipe out repository & force clone
in pipelines, you would use checkout step
checkout([$class: 'GitSCM',
extensions: scm.extensions + [[$class: 'WipeWorkspace']] + [[$class: 'PruneStaleBranch']],
userRemoteConfigs: [[
url: '<git_url>'
]]
])
there are other ways to clean a workspace in a pipeline like cleanWS and deleteDir. Do prefer the checkout WipeWorkspace plugin
So my situation is that I finally finished configuring TeamCity for CI. I got it to run my unit tests with some friendly help on SO.
However, many unit tests fail because there needs to be a config file alongside the unittests.dll once it's built and ready to run.
I've written a simple Command Line step with:
copy %system.teamcity.build.checkoutDir%\xx.configfile <destination>
The destination is the problem, I need it to be the Out directory teamcity creates.
TC creates SYSTEM_<machinename> <datetime>\OUT. An example:
C:\TeamCity\buildAgent\temp\buildTmp\SYSTEM_GIDEON 2015-07-02 16_51_09\Out
In there is my unittests.dll and I want to copy my config file there. What environment var or (anything else) can I use in the command line script?
The (1) Build Tests is a Step then I want to run the (2) Copy Config Step Then (3) Run Tests. After step (1) I have that xxx\xxx\Out directory and I need that directory from some variable.
I'm using Teamcity 9.0.2
Your problem is not to do with TeamCity I don't think, it's to do with the way that MSTest works. You need your .config file to be a DeploymentItem and have your tests deploy it to the directory that MSTest will run the tests in.
To be honest I'm surprised that you don't have this problem running locally, and it makes me think that you must be using some other test runner (like ReSharper) to run the tests if you have not seen this problem on your local machines.
I'm using Jenkins to build my projects on Maven 3.
There is ~15 jobs defined. They are running onCommit or by cron expression all day long (mostly once per hour). Some jobs are using Sonar (XXXDailyBuild not).
Sometime I'm facing error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:2.4.1:clean (default-clean) on project xxx: Failed to clean project: Failed to delete E:\CI\data\jobs\XXXDailyBuild\workspace\XXX\xxx\target\surefire\surefirebooter8004371362793469171.jar -> [Help 1]
It is caused by locked Jenkins workspace by active java process of surefirebooter8004371362793469171.jar
Jenkins job runs with 'Execute concurrent builds if necessary' disabled.
Any other job/process do not use 'XXXDailyBuild' workspace.
I'm trying to figure out what's going on.
Is there any way to dump running 'surefirebooter8004371362793469171.jar' process to analyze their heap?
Problem has been investigated:
Our application runs JUnit tests by surefirebooter maven plugin jar
Every tests need fresh models state
During models initialization old models state are disposed and fresh are initialized
Some models starts threads ie. Directory Watcher
The root PROBLEM is:
1. when some test fails in step 3. old models state aren't disposed
and this way some threads aren't stopped (duplicated on every test fail)
It was easy to check it using jvisualvm tool.
Finally, after maven test run process stays active forever.
Hope this analysis help someone!
Don't know the root cause and resolution. However, you can kill the java.exe from Task Manager (in Windows). This java.exe holds a lock on surefirebooter.jar file. Killing java.exe will Release that lock and you will be able to run the Maven Build.
i'm new to world of continuous integration and software developement.
I wanted to try hudson so i installed it on my ubuntu machine and created a new job. i pointed it to an open source project's svn (keepassx) just to try.
Hudson downloaded everything from the repository and marked blue for successful build.
aren't i suppose to be able to execute the software now somehow ? i thought once it is built i can run it, but i can't find any executable in the project's home page under hudson user home dir.
thanks.
A Hudson/Jenkins build breaks down into three steps:
update source code in workspace
run build
publish build artifacts
It sounds like you've got step 1 covered.
If the project you linked to has instructions for building (ant, maven, etc.), you can enter these as build steps into the "Build" section of the project configuration.
You can then take the resulting files ("artifacts"--jar, exe, so, bin, whatever) and publish these using the "Post-build Actions", or if necessary you can grab them directly from the workspace filesystem.
Assuming the build artifact was an executable, you could then run it after downloading it from Hudson, or make a build step or post-build action which moved it into the appropriate location and ran it.
It helps to run the build locally before trying to get Hudson to handle it--then you know what the build steps are, and what the final build artifacts are.
How would jenkins/hudson know how to 'execute' some arbitrary package that you told it to download and build? It's up to you to write a program or script to run what you want to run, and then make a downstream job (for example) to do so.
Is it possible to Trigger an exe to run on a failed build? Can you do this within Team City?
If you specifically want the failed builds, you can set up the dependent build as Eric said, and have that secondary buildscript use the REST API to pull up a list of the failed builds for the actual project.
If the latest build is in that failed builds list, then tell the build script to run the executable. If not, then you're all done!
http://confluence.jetbrains.net/display/TW/REST+API+Plugin
I don't think it's possible to trigger an executable to run only on failed TeamCity builds. TeamCity usually allows you to do things either always or only upon successful builds.
It would be possible to trigger an executable to run after this build is finished (failed or successful).
If that would work for you, you could set up a new build configuration that runs the executable. The new build configuration would have a "finish build" trigger. This would cause the executable to be run whenever the other build is completed.
You should add another build step with the exe you want to run and set the correct option to execute.execution options