Re: Expanding Parameters when triggering Jobs

Yeah, that's what I was hoping to avoid. Simply choosing "Use Current Parameters", and have it auto-magically include the evaluated value ... which is not feasible, so I'm trying to do something it's not meant to do. Hence, thread closed ;) On 19 September 2014 02:13, Jan Seidel wrote: > >

Re: Expanding Parameters when triggering Jobs

Ah, I got your point :) use the "Predefined parameters" opton. Then the variables will expand. See picture attached Am Dienstag, 16. September 2014 03:21:03 UTC+2 schrieb Brantone: > > Perhap

Re: Expanding Parameters when triggering Jobs

"${WORKSPACE}" was a poor example ... how about "${SOME_RANDOM_FOLDER}" .. the point was, when param goes to get passed, it doesn't evaluate any nested parameters, just passes it straight text. On 19 September 2014 00:46, Jan Seidel wrote: > ${WORKSPACE} is dynamic. > Job A and job B have their

Re: Expanding Parameters when triggering Jobs

${WORKSPACE} is dynamic. Job A and job B have their own defined workspace and will use different values. If you want job B to use the same you could pass the value as parameter like: ALT_WORKSPACE=${WORKSPACE} Am Dienstag, 16. September 2014 03:21:03 UTC+2 schrieb Brantone: > > Perhaps just no

Re: Expanding Parameters when triggering Jobs

For anyone wondering, I can't remember where I read it, but it doesn't evaluate it unless you pass it as predefined. When using "current build parameters" it just does it exactly as is, as if it was typed in that way. The mention/verification was in a random comment somewhere, just can't find it

Expanding Parameters when triggering Jobs

Perhaps just not using the right terms to look for an answer as I'm thinking this isn't crazy unique. So "Job A" triggers "Job B". Job A has a parameter called PROJECT_PATH, whose value = "${WORKSPACE}/project/trunk/". When triggering Job B choosing "Current Build Parameters", It passes it st