I have just started getting Jenkins setup with Phing as the build tool. Although I have used Jenkins before, I'm new to Phing.
I have a project setup in Jenkins that has a Mercurial Repository setup and a Phing Build step.
The build.xml file simply archives the existing file, deletes them and copies the new files from the repository.
I have run phing from the terminal and everything works as planned. However, when running from within Jenkins, I'm getting the following in the Console Output:
[workspace] $ /usr/local/pear/bin/phing -buildfile /Users/Shared/Jenkins/Home/jobs/Project/workspace/build.xml "-Dwebroot=/Volumes/Websites/Project/ -Dcheckoutroot=/Users/Shared/Jenkins/Home/jobs/Project/workspace -Drevision=5" -logger phing.listener.DefaultLogger
/usr/local/pear/bin/phing: fork: Resource temporarily unavailable
Build step 'Invoke Phing targets' marked build as failure
My first thought was that it was permission related, but I've changed Jenkins to run as the same user that I ran Phing manually as and it still got the same issue.
Does anybody have any thoughts as to what might be causing the problem?
I can't find anything related to this error anywhere that isn't related to Cygwin...
The system is running on OS X 10.7.5 with Jenkins 1.518 and Phing 2.5.1
The build.xml file looks like:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Project" default="dist">
<property name="revision" value="old" />
<property name="webroot" value="/Volumes/Websites/${phing.project.name}" />
<property name="checkoutroot" value="./" />
<target name="clean">
<echo msg="Backing up old site to ${phing.project.name}-${revision}..." />
<tar destfile="${webroot}/../${phing.project.name}-${revision}.tar.gz" basedir="${webroot}" compression="gzip" />
<echo msg="Deleting site from ${webroot}..." />
<delete>
<fileset dir="${webroot}" />
</delete>
</target>
<target name="dist" depends="clean">
<echo msg="Copying files to website at ${webroot}..." />
<copy todir="${webroot}">
<fileset dir="${checkoutroot}/Website">
<exclude name="**/.hg/**" />
</fileset>
</copy>
</target>
</project>
I've managed to resolve this issue by removing all of the path details in the Phing configuration section within Jenkins.
This makes absolutely no sense to me as to why it's working without these details as I definitely only have one Phing install, so it's not as if it was picking up the wrong one or something.
However, by not specifying anything in the Phing section of the Jenkins project config so it picks up the default path, default build target etc. and this is working flawlessly now!
Related
I'm having some trouble freeing component builds from JDeveloper Studio...
I have a reference to aia.jar set up in JDeveloper, which I can't seem to specify correctly on the Ant command line.
Here's my command line:
ant -f c:\...\jdeveloper\bin\ant-sca-package.xml
-D"compositeDir=c:/.../ProcessImpl"
-D"compositeName=ProcessImpl"
-D"revision=1.0"
-D"scac.application.home=c:/.../.adf"
Everything seems to go well at first, until it fails with: package oracle.apps.aia.core.eh.logging does not exist
Here is the solution, for the sake of anyone that has the same issue in future...
My aia.jar lived in jdeveloper/lib ...
I had tried the CLASS_PATH environment variable, the -lib <path> option on the ant command line, and even adding to the classpath property in ant-sca-compile.xml - none of which made any difference.
The aia.jar file apparently HAS to exist in the SCA-INF/lib subdirectory of the project being built. In the end I created a wrapper build.xml file that copies the required dependency to this location and then calls out to ant-sca-package.xml...
<target name="build">
<echo>Copy AIA.jar</echo>
<mkdir dir="${sca-inf.dir}/lib" />
<copy file="${aia.file}" todir="${sca-inf.dir}/lib"/>
<echo>Create Package</echo>
<ant antfile="${script.home}/ant-sca-package.xml" inheritAll="false" target="package">
<property name="compositeDir" value="${path}/${name}"/>
<property name="compositeName" value="${name}"/>
<property name="revision" value="${rev}"/>
<property name="sca.application.home" value="${adf.dir}"/>
<property name="scac.application.home" value="${adf.dir}"/>
</ant>
</target>
I am running build with next targets:
<Target Name="BeforeCompile">
<Message Text="Build no: $(BuildNumber)" />
</Target>
Then in between I run build (using nmake). After that I want to deploy firmware:
<Target Name="AfterCompile">
<MSBuild Projects="$(MSBuildProjectFile)" Targets="CustomDeployMagicFirmware" Properties="Id=1" />
</Target>
<Target Name="CustomDeployMagicFirmware">
<Message Text="...Deploying bootloader files to build machine - folder: $(BuildNumber)" />
<Exec Command='xcopy "$(SolutionRoot)\Repository\bootloader\*.axf" \\machine\bootloader\$(BuildNumber) /y /q'/>
<Exec Command='xcopy "$(SolutionRoot)\Repository\bootloader\*.hex" \\machine\bootloader\$(BuildNumber) /y /q'/ -->
</Target>
The problem is that in target "BeforeCompile" I get properly message output for $(BuildNumber). But later I have Message Test output like:
...Deploying bootloader files to build machine - folder:
There looks like variable $(BuildNumber) is not set anymore. Also command xcopy copies files to folder bootloader and not to folder bootloader\$(BuildNumber).
What do I do wrong? Which things can influence variable contents?
The error is in this line
<MSBuild Projects="$(MSBuildProjectFile)" Targets="CustomDeployMagicFirmware" Properties="Id=1" />
The MSBuild task spawns a new MSBuild.exe process and you are not passing the property $(BuildNumber) to the new process. Change it like below and this would work
<MSBuild Projects="$(MSBuildProjectFile)" Targets="CustomDeployMagicFirmware" Properties="Id=1;BuildNumber=$(BuildNumber)" />
Use <CallTarget> instead of <MSBuild> to invoke your CustomDeployMagicFirmware target.
I want use Ant to automate build, deployment,starting & stopping server of applications.
I'm able to build the application through Ant and copied the war file into the Tomcat webapps directory.
On the Internet, I found this article which contains more code to start and stop Tomcat. Since I can successfully deploy without those, I was wondering why they are there.
The code for my build.xml is below.
<?xml version="1.0"?>
<project name="Test" default="build-war">
<property file="build.properties"></property>
<target name="build-war" depends="clean">
<war destfile="Test.war" webxml="${web.dir}/WEB-INF/web.xml" >
<fileset dir="${web.dir}">
<include name="**/*.*"/>
</fileset>
<classes dir="${build.dir}/classes"></classes>
</war>
<copy todir="${deploy.path}" preservelastmodified="true">
<fileset
dir=".">
<include name="*.war"/>
</fileset>
</copy>
</target>
<target name="clean" description="Clean Test war directories">
<delete>
<fileset dir="${deploy.path}">
<include name="Test.war"/>
</fileset>
</delete>
</target>
</project>
There is no reliable way to (re)deploy an application to a web server. The reasons why an app might fail to deploy are numerous (thread leak, shutdown hooks, accessing parent classloaders) but in the end, there is no reliable way to tell whether a (complex) application could be deployed successfully.
This means that most developers have learned to use this cycle:
Deploy. Tomcat should automatically notice the new files and restart.
If something is odd, try to reload (ReloadTask). This tells Tomcat "no matter what you believe, the app has changed! Start it again!"
If the app still fails, stop and start Tomcat again.
If that fails, stop tomcat, delete all files, deploy again and after deployment, start Tomcat again.
If that fails, delete Tomcat and all files, reinstall, ...
Yes, I once had a script which could do every of the steps above. :-)
In the end, I gave up on deployment. My current solution is to write a Java application which creates an embedded Tomcat or Jetty server, configures it and starts the app. I have just a single classpath. No file copying, deployment or any such nonsense necessary. That way, I just have a single process, only a single web app in the container and I have all logs in one place.
I have the following problem - I'm running a checkstyle ant task when building with Jenkins and the respective report DOES get produced, but the thing is that when the build finishes I get a message that there has been an error during the parsing because the error report has not been found. I verified that I have set the path to the report that is to be published to the right thing (when I change it to something slightly different I get a message that xxx does not exist but the path from the previous version does exist). Any idea what might be wrong? What format is Jenkins expecting in order to publish the checkstyle report? I'm using the following build.xml
<taskdef
classpath="libs/checkstyle-5.6-all.jar"
resource="checkstyletask.properties" />
<target name="checkstyle" >
<checkstyle
config="checkstyle.xml"
failOnViolation="false" >
<fileset
dir="src"
includes="**/*.java" />
<formatter type="plain" />
<formatter type="xml" />
<formatter
toFile="checkstyle-result.xml"
type="xml" />
</checkstyle>
<style
style="checkstyle-noframes.xsl"
in="checkstyle-result.xml"
out="checkstyle-result.html" />
</target>
the config is the sun-checkstyle config.
Thanks for any help.
Try specifying **/checkstyle-result.xml as the result file location in your Jenkins job configuration; that will look through your entire build workspace for the result file. You can tighten up the file glob once you have things working.
If the above doesn't work, post the error message you're getting from Jenkins and the location of checkstyle-results.xml relative to your job's workspace directory.
From the checkstyle plugin website:
The Checkstyle plug-in scans for checkstyle-result.xml files in the
build workspace and reports the number of warnings found.
The plug-in should be looking for the checkstyle-result.xml XML formatted file. You don't mention in your question how you've configured the plugin, but if you are looking for checkstyle-result.html that may be the issue.
I have setup an ant script as eclipse builder to automatically run all my tests, like below:
<project name="auto-test" default="test">
<property name="tst-dir" location="C:\STAF\services\custom\TopCoder\bin" />
<path id="classpath.base" />
<path id="classpath.test">
<pathelement location="D:\eclipse\eclipse\plugins\org.junit4_4.3.1\junit.jar" />
<pathelement location="${tst-dir}" />
<path refid="classpath.base" />
</path>
<target name="test" description="Run the tests">
<junit>
<classpath refid="classpath.test" />
<formatter type="brief" usefile="false" />
<test name="testDataGenerator.test.AllTests" />
</junit>
</target>
</project>
It was all good before I changed a test fixture file from absolute path to relative path:
SAXReader reader = new SAXReader();
Document document = reader.read(new File(".").getCanonicalPath()+"\\conf\\TestData.xml");
The ant task now try to open D:\eclipse\eclipse\conf\TestData.xml, instead of C:\STAF\services\custom\TopCoder\conf\TestData.xml, I've also try to run AllTests manually from Eclipse and it's all good.
Has anyone met similar problem before?
Thanks in advance.
PS. ANT_HOME=D:\eclipse\eclipse\plugins\org.apache.ant_1.7.0.v200706080842
Follow up:
I tried to run the ant script from command line, and find below:
C:\STAF\services\custom\TopCoder>ant -f c:\STAF\services\custom\TopCoder\task\build.xml, the ant script works correctly.
C:>ant -f c:\STAF\services\custom\TopCoder\task\build.xml, the script will claim: [junit] C:\conf\TestData.xml (The system cannot find the path specified)
I've also checked eclipse builder setting, there seems nothing to change the path to D:\eclipse\eclipse.
Java resolves relative paths against the current user directory, which is typically the directory from where the java program was invoked.
One way to overcome this issue is to define an environmental variable for your base path. Then, you could easily use "relative paths" (meaning, create absolute paths by concatenating the base path and the relative path).
Here is the solution I find:
Just as kgiannakakis mentioned, Ant also start executing its task from the location it was invoked, so we just need to change the working directory setting of our custom eclipse builder.
In the JRE tab, choose "Execution Environment".
Change the Working directory to your current workspace.
Looks like I've missed the karma but anyway...
We do this:-
Build.xml
<project name="whatever">
<property file="build.${env.COMPUTERNAME}.properties"/>
<property file="build.properties"/>
build.properties
project.root=..
build.file.dir=${project.root}/buildfiles
deploy.dir=${project.root}/deploy
which of course you can override by creating your OWN build.computername.properties to allow for developer path differences etc