RUBYLIB environment variable ignored in Rake build step

Hi
I'm using Rake for our unit tests. In the developers' environments, they update the RUBYLIB environment variable on their PCs to point to a directory of custom ruby classes to support the tests. This works fine in their environments.
set RUBYLIB=C:\Users\<...>\Documents\SVN\QA\test\lib

I'm trying to recreate that now in TeamCity, such that the RUBYLIB environment variable is dynamically updated based on the agent's working directory.

In the configuration Build Parameters I have:
env.RUBYLIB = %teamcity.build.workingDir%\QA\test\lib

There is a corresponding VCS root that pulls these files from SVN, such that the \QA\test\lib directory is always checked out into the agent's working directory

When the agent runs the build, I see the RUBYLIB environment variable is updated correctly, but rake can't seem to find the files

I tried running it manually, by opening a command window directly in the agent's working directory and setting RUBYLIB to the same path as the build:
set RUBYLIB=C:\TeamCity\buildAgent\work\ae1edd57fba32e1c\QA\test\lib

When I ran rake from this local command window, it worked fine

Is there any way the agent is not "loading" the environment variable properly, which would cause Rake to not find the necessary files?

thanks
Michael

7 comments
Comment actions Permalink

Hi Michael,

I cannot reproduce your bug.
env.RUBYLIB = %teamcity.build.workingDir%\lib\ works fine on  my both Linux & Win agents.
variable patched and Rake works.

Could you please show build configurations on which rake runner fails.

Please attach log of running this Rakefile via one of build steps:

task :showEnv do
  for i in ENV.keys.sort do
    puts i+" = "+ENV[i]
  end
end


just to be sure that variable really patched.
0
Comment actions Permalink

Hi Vladislav
I did a little more experimenting, and I found the problem - but still not sure what the solution is.

It turns out, it's not the RUBYLIB environment variable, but another custom one: env.FW_ROOT
A handful of our ruby scripts use relative paths to this environment variable, so developers can checkout the code wherever they want, and just set a single environment variable on their workstations

What is happening is TeamCity is 'manipulating' this environment variable, for some reason.

  • In my Build Parameters, I set the env.FW_ROOT parameter to: %teamcity.build.workingDir%
  • The VCS root is set accordingly, and TeamCity properly checkouts the repository, and all the scripts are placed in the correct relative directory structure


The problem is with a specific build step. I have a setup build step with the following parameters:

  • Runner Type: Command Line
  • Working Directory: RubyScripts
  • Command Executable: ruby.exe
  • Command Parameters: setup_script.rb


Basically, I have a directory called \RubyScipts which contains a script called "setup_script.rb", which is called from the command line, to prepare the target for testing
What is happening is this:

When I add puts ENV['FW_ROOT']inside the setup_script.rb file, in the build log I see:
C:\TeamCity\buildAgent\work\a852d8558300ae2e\RubyScripts

This is wrong. For some reason TeamCity is appending the Working Directory for this build step to the environment variable. This is not intended, and I can't see where this is being setup to do so
As a result, all the scripts using relative paths to ENV['FW_ROOT'] can't find their target files, since there's an extra '\RubyScript' in the path

If I look at the Build Parameters page for the build, I see env.FW_ROOT is properly being parsed as just C:\TeamCity\buildAgent\work\a852d8558300ae2e

Any suggestions? I'm running TC 6.5.3

thanks
Michael

0
Comment actions Permalink

Hi Michael

If you  set the env.FW_ROOT parameter to: %teamcity.build.workingDir%
and in  specific build step set working dir as "./RubyScripts"  you will have "TeamCity\buildAgent\work\a852d8558300ae2e\RubyScripts" (see description)

You may use %teamcity.build.checkoutDir%

Also see reference about properties.

0
Comment actions Permalink

Vladislav
That worked. Thanks

For some reason, I thought  %teamcity.build.checkoutDir% evaluated to just the hash directory, not the full path, so I didn't originaly use it

However - this brings up a new question about the order of operations for evaluating build parameters.
In the help file link you sent (http://confluence.jetbrains.net/display/TCD65/Predefined+Build+Parameters#PredefinedBuildParameters-AgentBuildProperties), it says teamcity.build.workingDir is "calculated on the agent right before the build start and are then passed into the build". But, this apparently isn't completely true.

From my example, %teamcity.build.workingDir% appears to be re-evaluated at each Build Step, instead of just once at the build start. And thus, any build parameters I created to use %teamcity.build.workingDir% were also re-evaluated at each build step

Even though I set env.FW_ROOT to %teamcity.build.workingDir% in the configuration's Build Parameters and intended for it to be evaluated just once and retain the same value throughout the build, it was re-evaluated at each build step.

  • At build start: env.FW_ROOT = %teamcity.build.workingDir% = C:\TeamCity\buildAgent\work\a852d8558300ae2e
  • At one of my command line build steps, I set the "Working Directory" field to \RubyScripts - which effectively overwrote %teamcity.build.workingDir% to equal C:\TeamCity\buildAgent\work\a852d8558300ae2e\RubyScripts which in turn, caused env.FW_ROOT to be updated to this new path
  • In the next build step, I left the Working Directory field empty, so %teamcity.build.workingDir% was re-evaluated back to C:\TeamCity\buildAgent\work\a852d8558300ae2e, and subsequently so was env.FW_ROOT


Am I interpretting the series of events, correctly? If so, I didn't see anything in the documentation about build parameters being re-evaluated at each build step. This seems very dangerous - especially since there's no indication in the Build Parameters page of the build log that the parameters were changing values

thanks
Michael

0
Comment actions Permalink

teamcity.build.workingDir is a path where TeamCity build runner is supposeed to start a process. This is a runner-specific property.
Build Agent re-resolves all references for each step, that is why you see changes in your environment variable.

There is 'teamcity.build.checkoutDir property that never changes while the build. The value of that property is that full path on agent to the directory where build sources were checked out. It seems you meant to you this property.

0
Comment actions Permalink

Eugene
Yes. I did mean to use checkoutDir, instead of workingDir.

The follow-up question is: where is the docmentation that says some variables (i.e. teamcity.build.workingDir) get re-evaluated at each step? And more importantly, which variables get re-evaluated?

thanks
Michael

0
Comment actions Permalink

Unfortunately, there is no such documentation for now. All variables are reevaluated on each step or change. Some variables are not changeble, like checkoutDir, workingDir

0

Please sign in to leave a comment.