8
votes

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

2
Sounds like you're doing something very odd, which I don't fully understand. Why is the build.xml file not located in the root directory of the project you're building? Normally you just configure the Jenkins pull the project files out of the SCM system and then run the build... All this happens within the "workspace" which Jenkins manages for that build job.Mark O'Connor
Why do you need the directory? You could use relative paths safelyEugen Martynov
@MarkO'Connor :- I have a generic build script that can be leveraged for several projects (there is a project-specific property file that the script pulls down to qualify what its doing, but I don't see the value, at the moment, in copying the same build.xml file across multiple, similar, projects).rguilbault
@EugenMartynov :- as stated in the question, my script is running out of one location (C:\vc-tools\shadow), the workspace is in another (%JENKINS_HOME%\workspace\<job>) and the build result is in yet another (E:\builds\<job>\%BUILD_ID%). I admit it is a little odd, since you would typically house your build.xml within the project root (or some relative directory), whereas I have mine in a completely unrelated location. I know of no way to relatively address E:\builds from C:\vc-tools\shadow (aside from hardcoding of course).rguilbault
@rguilbault I missed point that your build script is inside another directory. Please ignore my comment :)Eugen Martynov

2 Answers

12
votes

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:

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>
5
votes

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>