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
Related
I am running a custom Jenkins 2.263.4 build on Travis-CI. We need a fix with relative pathes that never made it into the Jenkins core...well for us it is mandatory.
Based on release 2.263.4 I applied the fix in core/SecretRewriter.java and core/VirtualFile.java and also changed the version name to give it branding. This worked very well in the past releases. But the last update we did was one year ago.
Now I am running into the error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.2.1:shade (default) on project cli: Error creating shaded jar: duplicate entry: META-INF/services/io.jenkins.cli.shaded.org.apache.sshd.common.io.IoServiceFactoryFactory -> [Help 1]
I am not able to understand it at all.
Travis-CI is here: https://travis-ci.com/github/DanielWeber/jenkins
GitHub: https://github.com/DanielWeber/jenkins
I was not able to find this exact problem from somewhere else. I tried a bit with the shade config to set
<minimizeJar>false</minimizeJar>
and similar small things, but didn't really help.
My change is so small, I don't really understand what's happening.
If nothing helps, I might consider doing changes step by step then, rather than just merging the releae to our for, but hope someone sees the problem.
The issue is that the build is being execute two times based on the mvn install followed by mvn package which is defined in travis.yml file. This causes the issue.
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.
Why would I run gradle clean build instead of gradle build?
From what I understand, Gradle can detect source changes and update the final artifacts if needed. So why would I still need to clean?
The clean task is defined by the java plugin and it simply removes the buildDir folder, thus cleaning everything including leftovers from previous builds which are no longer relevant. Not doing so may result in an unclean build which may be broken due to build artifacts produced by previous builds.
As an example assume that your build contains several tests that were failed and you decided that these are obsolete thus needs to be removed. Without cleaning the test results (using cleanTest task) or the build entirely (by running the clean task) you'll get stuck with the failed tests results which will cause your build to fail. Similar side effects can happen also with resources/classes removed from the sources but remained in the build folder that was not cleaned.
It removes the build directory. (Build contains the output of the gradle operation)
Other build tools like buck will detect that some tests are removed and won't run them without the needs to run clean target. I think this is pitfall of gradle.
You don't need to run the clean task.
Gradle will track task dependencies and clean appropriate parts for you.
Here's an example Gradle project I created to show that the accepted answer is incorrect.
If custom tasks don't track their dependencies well (they're bugged), then clean is a workaround.
Is it possible to make TeamCity only clean up certain files upon fetching files from my git repo? I modify one file as a build step, and thus always need a clean version of that file. However, it's really unnecessary to fetch the whole repo everytime because usually only a few files are modified (thus, I'd rather not use the 'Clean all files before build' command).
Thanks!
To clarify, lets say I have the following structure:
- index.html
- js/script.js
- js/plugins.js
I only want to always (regardless if any change has happened) to checkout index.html. The files in the js folder I only want to replace whenever any updates on them have happened.
If you are using TeamCity 6.5 or above you can use the Build Files Cleaner (Swabra) Build Feature. Once you have added it your build steps and run clean build it will clean any new unversioned files generated during the build either before the new build starts or at the end of the current build.
I personally prefer to run it before the new build starts as it allows you to look at any of the output when trying to work out why something went wrong.
Basically it makes sure that there is nothing in the build agents work folder that was not pulled from the repository before each 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.