Variable Run Condition scoped for target machine

[pnolan]

Hi,

I have a Process called e5Anywhere which contains a group step called “e5 - Deploy e5Anywhere Repositories and Data” with two child steps.

The group step has a Variable Run Condition with the value #{e5.Anywhere.Repository.RunScripts}.

The Variable #{e5.Anywhere.Repository.RunScripts} should evaluate to True for Target Machine e5Workflow_prdoctotest and False for Target Machine e5Workflow_prd2013 based on variable scope conditions.

Both machines e5Workflow_prdoctotest and e5Workflow_prd2013 are in the Test Environment.

When the e5Anywhere process is executed for the Test Environment the group step and its children are executed for both e5Workflow_prdoctotest and e5Workflow_prd2013.

Is this expected behaviour? How can I ensure he group step and its children are only executed for a target machine based on a particular variable?

I have attached the process output and a screencast showing setup in case it helps.

ServerTasks-11603.log.txt.7z (459.2 KB)
RunCondition.mp4 (882.2 KB)

[Kenneth_Bates]

Hi,

Thanks for getting in touch and providing all of that fantastic information! Unfortunately this is currently a limitation with the run conditions. The run condition is evaluated once for the entire step, instead of once for each deployment target scope. So machine-scoped variables just aren’t possible to be used when evaluating a run condition.

We have an open enhancement issue to address exactly this that you can track. (I’ve included this forum link in there to bump it up.)

Issue: Variable Run Condition should ideally be evaluated on a machine level to allow for machine scoped variables

The only workaround I can think of is to use role-scoping on the steps, and give your machines these unique roles as required, but it doesn’t sound like a nice clean solution going forward. Sorry it’s not better news!

Let me know if you have any further questions going forward.

Kind regards,

Kenny

[pnolan]

Thanks Kenny hopefully that enhancement will get added soon…seems like something which alot of people would need.

In the mean time, is there any logic I can add to a pre-demployment script for a step that would use a scoped variable to silently abort the step?

[Kenneth_Bates]

Hi,

Thanks for following up! I’ve done some further testing in hopes of reaching a good work around, but unfortunately the only thing that I think would currently work is to scope a step to a unique role in which you only assign to a single machine (or subset of machines depending on how many you want to run it on). I agree this would be a great enhancement, and I’m planning on bringing this up with my team soon.

Sorry it’s not better news for the time being! Let me know if you have any further questions.

Kind regards,

Kenny