Robin Shen [29/Nov/06 04:16 PM] How about referencing variables when define your environments, and override these variables in child configurations? Regards. Robin

Don Ross [29/Nov/06 04:20 PM] How can I define a user environment variable in a child configuration?

Robin Shen [29/Nov/06 05:16 PM] You can define environments like below in builders of root configuration: env1=${var["var1"]} env2=${var["var2"]} And define var1 and var2 in basic settings of the root configuration with default values: var1=default-value1 var2=default-value2 Then in child configuration, you can selectively override these variables, for instance, var1=value1 In this way, env1 for builder of that child configuration will take the value of "value1" instead of "default-value1". Regards. Robin

Don Ross [09/May/11 03:32 PM] Hello again (after a long hiatus). I see what you are saying and I see how it can work. However, it doesn't help the need to define the environment variables for every builder. What I was (and still am) looking for is a way to define an environment variable, similar to to how variables are set up in the Defined/Inherited variable tab, which applies to all builders in the configuration.

Robin Shen [09/May/11 10:38 PM] Since there is no vote on this feature, we postponed it. If you look for global environment variables, how about defining them at OS level?

Don Ross [18/May/11 03:57 PM] If I do that, then they become per-node variables. I was looking for per-configuration variables which work across all nodes. However, I may be able to have a step at the beginning of my build which uses 'setx' to define an environment variable on the node, which should then be visisble in all subsequent steps of the build. Does that sound reasonable?

Robin Shen [18/May/11 11:06 PM] This will not work. As each step runs in its own command shell and will not seen environment variables set by other steps. To solve this, we need to add the concept of global environment variables which need to be defined as a configuration setting. We will try to deliver this feature in QB4.

Don Ross [10/Jun/11 07:35 PM] setx creates a system or user environment variable which should be visible to subsequent tasks; however, it probably requires a restart of the service before the new variable is picked up. Thank you for investigating this as a product feature. No other build tool has this.

Don Ross [03/Aug/11 03:12 PM] I have implemented a workaround for this which is to have an initial step in my configuration which creates a batch file defining the environment variables I need. Then, every subsequent step which runs in the environment calls this batch file before This prevents me from using the ANT or MSBUILD plugins since I have to do everything from the command line. Do use the plugins, I would need to create an ANT or MSBUILD properties file which is then loaded by each subsequent task, but those tools lack the sophistication for that operation, which is why I am seeking the capability in QB. I thought you may find this line of reasoning useful.

Robin Shen [20/Nov/13 02:18 AM] This can now be achieved by defining environment variables in composition steps. Environment variales defined there can override those defined in parent step and will be inherited by all build steps underneath it.