Build definitions and local JBE properties
I have many instances of a JBE using the same engineId. But since each
JBE is running on a different physical box, the location of the tools
(and other things) needed to run a build is (or might be) different on
each build machine.
My builds are all command-line, not Ant or Maven.
I believe that within a Build Definition, I can't refer to local JBE
environment variables or JBE JVM properties. Am I right ?
If so, is the following an enhancement that might be considered ?
The RTC Build Engine definition and Build Definition should allow local
JBE environment variables or JBE process properties to be referenced
within the Build Engine definition or the Build Definition.
e.g.
On the build machine, the JBE is started with its own property(ies)
JBE -DTOOLS=c:\mytools .....
Then, within my Build Definition, on the command-line tab I can ask RTC
to run the following build command:
${TOOLS}/run_my_build
${TOOLS} has a different value on each JBE and its value can only be
resolved by each individual JBE.
JBE is running on a different physical box, the location of the tools
(and other things) needed to run a build is (or might be) different on
each build machine.
My builds are all command-line, not Ant or Maven.
I believe that within a Build Definition, I can't refer to local JBE
environment variables or JBE JVM properties. Am I right ?
If so, is the following an enhancement that might be considered ?
The RTC Build Engine definition and Build Definition should allow local
JBE environment variables or JBE process properties to be referenced
within the Build Engine definition or the Build Definition.
e.g.
On the build machine, the JBE is started with its own property(ies)
JBE -DTOOLS=c:\mytools .....
Then, within my Build Definition, on the command-line tab I can ask RTC
to run the following build command:
${TOOLS}/run_my_build
${TOOLS} has a different value on each JBE and its value can only be
resolved by each individual JBE.
3 answers
David Ward wrote:
The standard advice is to not do that. Each build engine process should
have its own ID. It's tedious to create all the build engine
definitions in the repository, but it gives you more control over which
builds run where, and it avoids the problem you described here.
I have many instances of a JBE using the same engineId.
The standard advice is to not do that. Each build engine process should
have its own ID. It's tedious to create all the build engine
definitions in the repository, but it gives you more control over which
builds run where, and it avoids the problem you described here.
Yes, we don't recommend running multiple JBEs for the same engine id. It generally works, but it can cause various problems. One (minor) effect is that the last contact time for the server-side representation of the engine will be inaccurate. And since there's only one, you can't tell if one of the JBEs dies.
But using environment variables has been requested before, and we're considering it.
See: 97931: Allow jbe to specify environment properties.
Using system properties as you suggest, instead of environment variables, is interesting, and is consistent with how Ant and Maven represent properties.
But using environment variables has been requested before, and we're considering it.
See: 97931: Allow jbe to specify environment properties.
Using system properties as you suggest, instead of environment variables, is interesting, and is consistent with how Ant and Maven represent properties.
In case it wasn't clear from the above, if you have separate build engine items, you can assign each one a TOOLS property with a different value for each, then use ${TOOLS} in the other fields.
If you really don't want to go with separate build engines, you could have the command line portion of your build do the substitution of environment variables, or run a script that does this then invokes the real command.
If you really don't want to go with separate build engines, you could have the command line portion of your build do the substitution of environment variables, or run a script that does this then invokes the real command.