Missing agent properties

I'm in the process of upgrading my TeamCity install from 4.0.1 to 4.5.3. The upgrade process described in the documentation was followed (my install is on Windows 2003 via MSI files).

Our builds are scripted with FinalBuilder 6, and run from TeamCity via the command line runner.

On TeamCity 4.0.1 all the properties (agent, build configuration, predefined, etc.) were available to the finalbuilder script. Specifically, we read teamcity.dotnet.nunitlauncher to determine the path to the nunitlauncher on a particular build agent.

On TeamCity 4.5.3 none (or very few) of the properties are available. FinalBuilder reports that the propertie do not exist. The environment variable TEAMCITY_BUILD_PROPERTIES_FILE does exist, and it points to a file (in the case of this particular build) C:\BuildAgent\temp\agentTmp\teamcity.build12122.properties, which in turn contains the properties I'm looking for - for example teamcity.dotnet.nunitlauncher.

My question is why are these properties no longer available in the environment, as they were in TeamCity 4.0.1?

Thanks for any help,

W.

9 comments

I guess you mean environment variable "teamcity.dotnet.nunitlauncher". Starting with 4.5.x TeamCity will not set such variables anymore because not all software likes dots in the environment variable names. There exists property with such name but if you are starting FinalBuilder build via the command line runner then properties are not available for you (properties make sens for some runners only: MSBuild, NAnt, Solution runners as well as for Java based runners like Ant).

However it is simple to restore such environment variable in your case. For this you should add environment variable on the 6th step of the build conf administration screens with name
teamcity.dotnet.nunitlauncher  and value %system.teamcity.dotnet.nunitlauncher%

Value %system.teamcity.dotnet.nunitlauncher% is a reference to property teamcity.dotnet.nunitlauncher and will be replaced when build starts.

0

OK Pavel, thanks for explaining that. It's particularly unfortunate in our case as out build scripts use these variables extensively. As I noted, the environment variable  TEAMCITY_BUILD_PROPERTIES_FILE points to a file on the buildagent that contains all the properties, and is availbe to a command line runner. Will that behaviour be continue to be available throughout the 4.X series, as we could parse that file to obtain our properties instead?

Thanks,

W.

0

Actually, I spoke too soon. I added the variable to my build configuration as you suggested, but unfortunately it does not work. The property is still not available within my build script, as it was under 4.0.1.

Are you aware of any other way to pass the property to the build script?

Many Thanks,

W.

0

How do you start your Final builder script? What runner do you use in TeamCity? Could you please attach screenshot of the 6th step of your build configuration?

0

We start our FinalBuilder script by calling it from the commandline, using the FinalBuilder command line runner. We use the TeamCity command line runner. The screenshot is attached, as requested. I've also attached a screenshot of step 3, to illustrate how we call FinalBuilder.

Thanks again for your help on this matter.

W.



Attachment(s):
step3.gif
step6.gif
0

You added property teamcity.dotnet.nunitlauncher but as I told before command line runner does not support properties. Properties are not applicable to command line tools. You should add environment variable with name: teamcity.dotnet.nunitlauncher and value %system.teamcity.dotnet.nunitlauncher%

0

OK Pavel, I will add as an environment variable, as you rightly suggested. Finally, are youable to answer my earlier question:

"The environment variable  TEAMCITY_BUILD_PROPERTIES_FILE points to a file on the buildagent that contains all the properties, and is available to a command line runner. Will that behaviour continue to be available throughout the 4.X series, as we could parse that file to obtain our properties instead?"

Thanks,

W.

0

Yes, this file will be available in the future versions. You can parse it if you wish, but suggested workaround with manually added env variable can be simpler.

0

OK, thanks Pavel.

I think parsing the file is perhaps easier when it involves altering 5 build scripts, as opposed to updating 50+ build configurations :-)

Thanks for your help, adding the environment variable works exactly as you suggested.

W.

0

Please sign in to leave a comment.