<target name="clone-repo" description="Pull code from SCM repository" depends="resolve">
<taskdef resource="org/eclipse/jgit/ant/ant-tasks.properties" classpathref="build.path"/>
<delete dir="${basedir}/omoc_build"/>
<git-clone uri="https://user:******#github.com/sirect/omoc.git" dest="${basedir}/omoc_build" branch="${branch}" />
<zip destfile="${basedir}/devtoolkit/devtoolkit_docker/config.zip" basedir="${basedir}/omoc_build/config" />
I want to run ant command where by default it should clone from main branch
Few things!
To answer your question, you can set the branch property in a properties file, which would be overwritten if you specify on commandline. Include the property file above your target:
<property file="defaults.properties" description="default configuration."/>
in defaults.properties you'll set branch to main and you could overide it with -Dbranch=non-main-branch
That allows you to set a default.
Now for the advice you didn't ask for:
Don't want ant cloning your source. You should have your build system checkout the source and then ant should build the source. You're creating a chicken and egg problem here... build.xml is in source control, and it's checking out source? That's fishy.
Related
I have PHP Project, that is hosted on GitHub.
Now, I'd like to configure Jenkins to run unit tests so that:
Whenever developer push/commits code to specific branch, it triggers corresponding PHPUnit build job.
If commit passes the unit tests, the source code is deployed (assuming I already have the required script to deploy).
The question is how to trigger the deployment script when source code passes the unit test (i.e. PHPUnit tests succeed)?
Please suggest to me the way to do that, which plugin I should try to achieve the result?
Thanks!
This is going to be a long post, as there's a lot involved, but it works a treat:
You will need:
Ant
Git Publisher plugin
Ant and phpunit will need to be on your PATH
Step 1: Configure your project
In your Jenkins, configure your project to 'Poll SCM' under the Git option. Leave the 'Schedule' as blank. Under 'branches to build' set that as the branch you want to build your release package from.
Reference:
Step 2: Run ant for every build
Add a build step to 'Invoke Ant'
If you don't use Ant already, create a build.xml file in your project root, add it to Git and have the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<project default="full-build">
<property name="phpunit" value="phpunit"/>
<target name="full-build"
depends="phpunit-unittests,-check-failure"
description="runs the tests"/>
<target name="phpunit-unittests"
unless="phpunit-unittests.done"
description="Run unit tests with PHPUnit">
<exec executable="cmd" failonerror="true" resultproperty="result.phpunit" taskname="phpunit-unittests">
<arg value="/c"/>
<arg value="${phpunit}"/>
<arg value="--configuration"/>
<arg path="${basedir}/phpunit.xml"/>
<arg value="--testsuite=Unit"/>
</exec>
<property name="phpunit-unittests.done" value="true"/>
</target>
<target name="-check-failure">
<fail message="PHPUnit did not finish successfully">
<condition>
<not>
<equals arg1="${result.phpunit}" arg2="0"/>
</not>
</condition>
</fail>
</target>
</project>
That will run all unit tests whenever the Ant task is invoked, which is now set for every time the project is built.
Then, install the Git Publisher tool. Configure as follows:
This creates a new release tag upon a successful build. You will use this later to publish the release to the final location. Note: There are different variables that Git Publisher provides for use, commit hash, user etc so use what you want. I stick to an incremental tag of v1.1.BUILD as that's a bit more standard.
Lastly, you will need to add a Git hook which will trigger a build upon a commit/push from any location.
Navigate to your repository folder and within that the 'hooks' directory.
Create a new file named 'post-receive' (you will see examples in there; overwrite this one). Place the following content in:
#!/bin/bash
while read oldrev newrev refname
do
branch=$(git rev-parse --symbolic --abbrev-ref $refname)
if [ "master" == "$branch" ]; then
curl http://YOUR_JENKINS_URL:8080/git/notifyCommit?url=YOUR_GIT_REPOSITORY_URL
fi
done
That should do the job nicely. I have left out implementation details of how you actually release your project as everyone does this differently. There are options to FTP files to a location, and all sorts. Personally I go into the folder where the application resides and do a checkout of the newly created tag - a one line command. Whatever suits your environment.
Other stuff I've ommitted but you will find useful - the Ant build task can do literally anything - In mine, I run composer to install dependences, run bower, run grunt, do syntax checking, coding standard checking, fire up selenium and run web tests, and a load of other stuff. It's a perfect combination of tools to automate the whole project deployment.
I am trying to create a build script, to migrate our build process from Cruise Control to jenkins, and I can't see how to get access to all the normal command line parameters when I call the MSBuild task.
For instance I would like to run the equivalent of
msbuild common.sln /p:Platform="$(MsBuildPlatformAnyCpu)" /p:Configuration=$(MsBuildConfiguration) /v:$(MsBuildVerbosity) /p:WarningLevel=$(MsBuildWarningLevel);OutputPath="$(ProjectBinariesFolder)" /fileLogger /flp1:logfile=$(ProjectBuildLogsFolder)\$(ProjectFile)_BuildErrors.txt;errorsonly /flp2:logfile=$(ProjectBuildLogsFolder)\$(ProjectFile)_BuildWarnings.txt;warningsonly /flp3:LogFile=$(ProjectBuildLogsFolder)\$(ProjectFile)_Build.txt;Verbosity=diagnostic
This is my msbuild file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="Build">
<PropertyGroup>
<JenkinsBuildFolder>C:\Program Files (x86)\Jenkins\jobs\build2\workspace</JenkinsBuildFolder>
<ProjectSourcesFolder>$(JenkinsBuildFolder)\Sources</ProjectSourcesFolder>
<ProjectBinariesFolder>$(JenkinsBuildFolder)\Binaries</ProjectBinariesFolder>
<ProjectBuildLogsFolder>$(JenkinsBuildFolder)\BuildLogs</ProjectBuildLogsFolder>
<ProjectTestLogsFolder>$(JenkinsBuildFolder)\TestLogs</ProjectTestLogsFolder>
<ProjectGuid>{F8A25B4A-589A-4D3D-A568-4700FD776250}</ProjectGuid>
</PropertyGroup>
<ItemGroup>
<ProjectToBuild Include="Common.sln">
<Properties>OutputPath=$(ProjectBinariesFolder);Configuration=Build</Properties>
</ProjectToBuild>
</ItemGroup>
<Target Name="Build">
<MSBuild Projects="#(ProjectToBuild)" />
</Target>
</Project>
However I have no idea how to get the task equivalent properties of the command line switches /v /filelogger etc
You can't.
/p is used to inject properties into the build from the command line. The other command line options like /v are specific to the build process and you cannot move them to the proj file.
Note that there was probably good reason why your Cruise Control setup specified those /p params. I suspect it is because the values for those params are defined in Cruise Control and it is a way to parametrize the build - so one could kick off a build and say $(MsBuildConfiguration) = "Debug". You may want to do the same with Jenkins and not hardcore the values.
As for the /p params, Jenkins allows you pass parameters to msbuild - see Default parameters below.
I am looking for property or settings which will override the default target/artifacts directory when we issue ant build command.
We have couple of modules and when we issue ant build, each modules creates artifacts under ./target/artifacts directory.
I want to override the output to custom directory. some thing like
./target/small/artifacts
./target/big/artifacts
based on the property which specifies which configuration to build. Either big/small.
Please let me know if there is any property/settings which can achieve this.
Can you just use normal Ant properties?
<!-- Default value if none specified. -->
<property name="artifacttarget" value="small"/>
<target ...>
<mkdir dir="target/${artifacttarget}/artifacts"/>
...
Then invoke:
ant -Dartifacttarget=small
ant -Dartifacttarget=big
I am trying to migrate an Ant script I wrote to build and deploy projects from within the Jenkins framework (instead of triggered from an SVN post-commit hook, which was the expedient way we initially approached things). Everything is great, except I need to stage files for the deploy step and I want to stuff them into the 'build' directory Jenkins creates for the job (and since my build.xml lives in a non-project-specific location, ${basedir} and ${user.dir} do not point to the desired location).
within the Jenkins configuration, I've setup the following:
[Jenkins]
Build Record Root Directory: E:/builds/${ITEM_FULLNAME}
[Job-Specific]
Build File: C:\vc-tools\shadow\build.xml
when running a build, the script is appropriately launched and a job-specific build directory is created, e.g.
E:\builds\Test\2012-08-07_12-51-21
I want to get at this directory from within the build script, but cannot figure out how. some of the things I've tried:
[echo] ${basedir}: C:\vc-tools\shadow
[echo] ${user.dir}: C:\vc-tools
[echo] ${env.workspace}: C:\Program Files (x86)\Jenkins\workspace\Test
[echo] ${env.build_id}: 2012-08-07_12-51-21
[echo] ${jenkins_home}: C:\Program Files (x86)\Jenkins
[echo] ${BuildDir}: E:/builds/${ITEM_FULLNAME}
note: for that last one, I tried passing in:
BuildDir=E:/builds/${ITEM_FULLNAME}
as a property configured from the job within Jenkins (clearly ${} expansion doesn't take place in this context).
according to the documentation, there are no specific environment variables that are set to the full build directory path -- I can fudge it by hardcoding the E:\builds root and tacking on ${env.build_id}, but was hoping there would be an easier way to access the complete path from something Jenkins exposes (either an Ant property and an environment variable) in order to make the script more flexible.
I am using Jenkins version 1.476.
thanks
It's always a good idea for your project to have a copy of it's build logic included alongside the source code. It makes your build more portable across machines.
Having said that it's also quite common to setup build files containing common shared build logic. ANT defines the following tasks to support such activity:
include
import
So a possible solution is to store a simple build.xml file, in the root of your project directory:
<project name="my project" default="build">
<include file="C:\vc-tools\shadow\common-build-1.0.xml" as="common"/>
<target name="build" depends="common.build"/>
</project>
Notes:
It's a good idea to use a revision number in the common build file name. This assists in preserving backward compatibility with other builds using the older logic.
Update
When Jenkins runs a job is sets a number of environment variables.
The following ANT logic will print the location of the Jenkins workspace directory:
<property environment="env"/>
<target name="run">
<echo message="Jenkins workspace: ${env.WORKSPACE}"/>
<echo message="Job directory: ${env.WORKSPACE}../../jobs/${env.JOB_NAME}"/>
<echo message="Build data: ${env.WORKSPACE}../../jobs/${env.JOB_NAME}/build/${env.BUILD_ID}"/>
</target>
These days (Jenkins v. 1.484) 'run' target from answer above should look like this:
<target name="run">
<echo message="Jenkins workspace: ${env.WORKSPACE}"/>
<echo message="Job directory: ${env.WORKSPACE}/../../${env.JOB_NAME}"/>
<echo message="Build data: ${env.WORKSPACE}/../../${env.JOB_NAME}/builds/${env.BUILD_ID}"/>
</target>
I have a build script and as part of that script it copies a jar file to a directory, for ease lets call it the utils jar. the utils jar is built by another build script sitting in another directory. What im trying to do have my build script run the utils build script so that I can ensure the utils jar is up to date.
So I know I need to import the utils build file.
<import file="../utils/build/build.xml" />
Which doesn't work because the import task, unlike almost every other ant taks, doesn't run from basedir, it runs from the pwd. So to get around that I have this little ditty, which does successfully import the build file
<property name="baseDirUpOne" location=".." />
<import file="${baseDirUpOne}/utils/build/build.xml" />
So now that ive solved my import problem I need to call the task, well that should be easy right:
<antcall target="utils.package" />
note that in the above, utils is the project name of ../utils/build/build.xml
the problem I'm now running into is that ant call doesn't execute in ../utils/build so what I need, and cant find, is a runat property or something similar, essentially:
<antcall target="utils.package" runat="../utils/build" />
The reason I need this is that in my utils build file the step to select which code to copy to the jar is based on relative paths so as to avoid hardcoding paths in my ant file. Any ideas?
I've got something similar set up: I have a main Ant build.xml which calls a separate build.xml that takes care of building my tests. This is how I do it:
<target name="build-tests">
<subant target="build">
<fileset dir="${test.home}" includes="build.xml"/>
</subant>
</target>
The trick is to use subant instead of antcall. You don't have to import the other build file.
Try using the "ant" task instead of the "antcall" task, which runs the imported build directly instead of importing it into the current build file. It has a "dir" parameter:
the directory to use as a basedir
for the new Ant project. Defaults to
the current project's basedir, unless
inheritall has been set to false, in
which case it doesn't have a default
value. This will override the basedir
setting of the called project.
So you could do:
<ant antfile="${baseDirUpOne}/utils/build/build.xml" dir="../utils/build" />
or something like that.
You can pass params down to antcall using nested in the antcall block. So, you can pass the properties down that way (probably even basedir since properties are immutable).