Reputation: 1540
My build script contains a local properties file that is used to set machine-specific values (such as base directory for the build). These are unique for each machine that the source is downloaded to.
When the build agent hasn't been run for a while, it removes the work folder for the project and ends up deleting the properties file. When a change is made later on (after a period of time in which the build agent has cleaned up the recently unused folder) the build breaks until the properties file is restored.
I am not certain whether the correct approach is to prevent TeamCity's build agent from deleting that folder/file (not sure how to accomplish this, which would seem the easiest solution) or have the build script try and generate the properties file when the build is run and the properties file doesn't exist.
Any suggestions are eagerly welcomed!
Upvotes: 3
Views: 2015
Reputation: 1540
Both of your suggestions would work. I ended up going with generating the file from a (checked-in) template file and modifying the properties for the machine.
@Mark Raymond: Your comment is very valid. TeamCity definitely doesn't make it easy. Your solution would work but I favored modification to the build script to generate the file because it would help other developers, who download the code fresh, get up and going without building a build-machine-specific solution.
@Gerald: That is, ultimately, what I had to go with. I've posted my Nant target below for reference:
The specific issue was setting a base directory that the other paths could be set relative to. Here is the solution I ended up going with:
<target name="assert.local.properties.exists">
<if test="${not file::exists('local.properties.xml')}">
<copy file="local.properties.xml.template" tofile="local.properties.xml" overwrite="false"/>
<xmlpoke
file="local.properties.xml"
xpath="/properties/property[@name = 'base.dir']/@value"
value="${directory::get-current-directory()}" />
<include buildfile="local.properties.xml" />
</if>
</target>
Upvotes: 0
Reputation: 977
Avoiding machine-specific behaviour is one of the aims of a build server, so TeamCity isn't designed to make it easy.
Regarding the specific property you mentioned, if the base directory for the build is always the same path relative to the checkout directory, you can set an environment variable in the build config, eg. setting env.BASE_DIRECTORY = %system.teamcity.build.checkoutDir%/build
.
Upvotes: 0
Reputation: 677
Where does this property file come from? Is it generated by your script?
TeamCity get the sources files from the source server, so potentially it can be cleaned, you cannot rely on files you would put in that sources after they are cloned.
What you could do is to have a copy of this file somewhere safe, and in your script, copy this file where you need it to be.
Upvotes: 1