I'm running an ant build through Jenkins and on the stage where it is deploying to windows-share its returning the following error:
Failed to copy FILE to FILE2 due to failed to create the parent directory for FILE2 (I've taken the paths out to keep the question shorter).
I'm guessing that there might be some problem with permissions with the jenkins default user but this problem has only just started occurring, and any help would be great.
Thanks
This is a pretty old question but I thought I'd come back and complete it with a short update as to what was actually going on. Someone had changed the password for the user that was logged on to the vm that jenkins was running on, and when it was trying to create the directory to stick the files into it was running into permissions errors. Only problem was the error message wasn't very descriptive.
So in the end this was an infrastructure problem rather than anything to do with the ant script.
I take it you're doing something like this:
<copy file="${from.dir}/${from.file}"
tofile="${to.dir}/${to.file}"/>
And, you're getting an error that ${to.dir} doesn't exist.
In earlier versions of Ant, you definitely had to create the directory before doing a copy:
<mkdir dir="${to.dir}"/>
<copy file="${from.dir}/${from.file}"
tofile="${to.dir}/${to.file}"/>
I think I also noticed that later versions of Ant will create the directory for you when that directory didn't exist. I've always been in the habit of putting <mkdir/> in front of any task that creates a new file in a new directory, including things like <zip/> and <tar/>.
Here are some questions:
Do your users also use Ant to run their builds? I know that this isn't always the case. Many users use Eclipse and don't bother with Ant.
Is the version of Ant your users have vs. what your users have the same?
Do you do a clean? Jenkins can emulate a clean either by doing an update, reverting and removing unversioned element, or by simply creating a brand new working directory. If your users don't remove the destination directory where ${to.file} is being placed, it might work locally, but not on Jenkins.
Can you manually run Ant from the Jenkins working directory. If so, what results do you get? (Remember to disable this Jenkins job before doing this. You don't want Jenkins to do a build while you're experimenting in the working directory.)
Related
I am completely new with Jenkins and have this question. So I created two projects on Jenkins. The first project will fetch from github if it notices any kind of change on my repo and will store a local copy on my machine.
The second project will start only if the first project is stable. If it is stable, the second project will first compile the all the java files (which I put in a compile.bat file), then it will run the testng.xml file which runs junit test and selenium test (run.bat file).
So what I want to do is if there is no compilation errors on compile.bat, then proceed on run.bat, but right now even though there are some errors on the java file and when the compile.bat runs, it catches those errors, Jenkins still proceeds to the run.bat file and at the end passes the build. I want the build to fail when there is any kind of errors.
Here is the link to my repo for the batch file and other files if that helps:
https://github.com/na2193/Demo
I had figured it out. You need to use conditional step(single) and there you can define what you want to do
I am actually trying to ignore a particular file to be included in the build. Actually it is a thumb.db file which is automatically created whenever images are encountered in a folder. My solution contains the image folder. So basically, whenever the build is triggered from JENKINS, it will create the thumb.db file.
Is there any way, I can ignore the Thumb.db file from getting created via JENKINS?
I can switch off the thumb.db file from creation by switching it off from my windows, but I have to do it every time a build is created from JENKINS. So I want to ignore the thumb.db file from creation.
Below is the Job creation flow in my JENKINS from my current project:
SCM
I have used the Team Foundation Server Plugin and have mentioned my SERVER URL and PROJECT PATH
POST BUILD steps simply create the build to the staging location(folder Location)
Any help is appreciated.
Thanks,
AFAIK, on windows you can turn it off or on for the whole system and not for particular folders.
So you have to choose. On or off.
If you still want to keep it on, you'l have to handle this in your Jenkins build scripts. Remove any thumbs.db files after build is done.
If your output is an archive, make sure to exclude thumbs.db from it. All archives support an exclude flag.
I hope this helps.
I used a very basic build file taken from the sample configure-was-derby.xml:
<property name="worklight.server.install.dir" value="C:/Worklight70"/>
<property name="config.migration.tool.enable" value="true"/>
<target name="minimal-update">
<updateapplicationserver id="" contextroot="/AreaClienti">
<project warfile="C:/temp/AreaClienti.war"/>
<applicationserver>
<websphereapplicationserver installdir="C:/WebSphere85/AppServer"/" profile="AppSrv01" user="wasuser" password="xxxxx">
<server name="server1"/>
</websphereapplicationserver>
</applicationserver>
</updateapplicationserver>
</target>
Recently I was able to reproduce the issue on my laptop installation and I believe I found the cause: please review the following analysis and confirm the results.
I originally installed the war file manually from WAS admin console, and when I run the Ant minimal-update with the above build file it failed with the mentioned error
The MobileFirst Project WAR file is not currently deployed in the WAS
profile at ...
Then I removed the manually installed war file and reinstalled it using Ant install target.
At this point the minimal-update run successfully.
I found out that the Ant installation created into WAS config structure
profile_root/config/cells/cell_name/nodes/node_name/servers/server1
a new Worklight directory containing the worklight-jee-library.jar file and a derby subdir with the derby driver jar.
Apparently the minimal-update Ant task makes a preliminary check on the existence of the Worklight directory and it fails if it's missing.
Can you please confirm that this is true ?
Of course the Worklight directory is not created by the standard WAS installation process.
So, after a console installation of the runtime war the Ant minimal-update always fails!
If I manually add the Worklight dir in WAS config, then the Ant minimal-update starts running just fine.
IMHO, altering in such way the standard WAS config structure is not very clean.
Said that, is it a valid workaround in case we initially install the runtime war with standard WAS admin procedures ?
Furthemore, also the returned error message could have been a bit more clear: please let me know if there is any debug option to make the Ant tasks more verbose.
At last, let me ask one further question.
I noticed that the Ant execution writes log files in the directory
user_root/.mobilefirst_platform_server
Is there any way to redirect those logs into a different dir to avoid the risk of filling up the user root ?
Apparently the minimal-update Ant task makes a preliminary check on the existence of the Worklight directory and it fails if it's missing. Can you please confirm that this is true ?
That's correct.
Is there any way to redirect those logs into a different dir to avoid the risk of filling up the user root ?
Unfortunately not.
Sorry, for the confusing title. I am totally new to Jenkins and have been handed over Jenkins to maintain which was set-up by someone else.
This is Jenkins Master slave config. I have 1 Master and 3 Slaves.
When I create a new job by "copying an existing" job, the new job works fine and no issues.
QUESTION: I see that in Jenkins workspace, this new job is creating a folder with the name of the original job that it was copied from. Why it is not creating a folder with the name of the new job instead?
Now, this is certainly not a show stopper for me, but it seems that Jenkins is creating a folder in workspace for each job that is run. And hence this particular folder is causing some confusion (although notional it is).
Hence, could you help me find out why the new job is creating a workspace folder with the name of original job it was copied from.
BTW, above issue was seen on the Jenkins slave.
It can be solved by configuring the correct building workspace in jenkins job.
General > Advanced > custom workspace > "give your correct workspace"
I had the same problem:
copied some jenkins project and wondered about hard coded workspace paths
Console output of the copied project. Job failed due to missing D: drive.
12:30:44 java.io.IOException: Failed to mkdirs: D:\TEAMS\WORKSPACE\RELEASE_1_1
The problem i had: the 'Advanced project options' were not expanded and the configure GUI had an enormous width, that i didn´t see the button to expand and show the 'advanced' settings.
In fact (thanks to sti): the original project had some hard coded workspace path.
One possibility is that you accidentally triggered the wrong job. You could change the job to print the directory where it executes by adding something like:
echo "XXX $JOB_NAME running in directory $WORKSPACE"
into the build step script. Then look for XXX in the build console log.
Second possibility is that you found an old workspace of the original job. Jenkins leaves workspaces lying around just in case it needs them again so it does not have to make them from scratch.
Third possibility is the original job is configured to use a hard-coded path as workspace. (Custom workspace). If you clone such a job, it would be a good idea to change the hard-coded path. An even better idea would be to let Jenkins manage the workspace and it's naming.
And finally, if all the other possibilities have been checked, you may have found a bug. You could look for it in https://issues.jenkins-ci.org/ and create a bug report if it is a new one.
I'm using Jenkins to do nightly build of an iOS static framework. The output that I care about is in this directory:
ios/build/Release-iphoneuniversal/MySpecialProject.framework
I'd like to use the "Archive the artifacts" action to archive "MySpecialProject.framework", but when I do this, it creates a whole archive with the entire leading directory structure. The docs say to look at how Ant does this. I'm not familiar with Ant, so I'm at a loss here.
The main point of this is to make the "MySpecialProject.framework" available as as artifact to other projects being built with Jenkins. So, thinking that I could use the "Copy Artifact" plugin to do that. But I can't really get past this thing where it creates a full directory structure here. I just wan "MySpecialProject.framework" to be the top-level artifact.
Thanks in advance.
I fixed my own problem, by putting in an "Execute Shell" command:
mv ios/build/Release-iphoneuniversal/MySpecialProject.framework .
Then in the post-build action, "Archive the artifacts", I was able to just archive "MySpecialProject.framework/**"
This seems to work quite well. Since each time Jenkins runs the job, it creates a new workspace, I don't have to worry about issues with "mv". Works fine.