A lot of our deployments rely on
OctopusBypassDeploymentMutex being set to avoid congestion.
When we run script console tasks or ActionTemplates “on demand” these will block other projects.
Is this intended behavior? When does the variable get evaluated by the server? Perhaps it would be possible to have a check box that would attach the variable to the
Task object behind the scenes?
Thanks for getting in touch! it is intended behaviour. That variable is only evaluated in context of a project and the variables available to a project. The script console and its ad-hoc tasks are not related to projects and will not evaluate variables or run conditions the same way a project will.
Our advice is always to create a project for tasks you will run more than once to get the benefits of project and deployment related features and functionality.
There are a few UserVoice suggestions for extending the script console to have these kinds of behaviour, but it is unlike to be a high priority as we believe a project is where to get the correct benefits and re usability.
Sorry if this is not the news you where hoping for.
I would be inclined to agree.
However, there are some scenarios where dynamic targeting would be ideal.
It seems like our choices are either “make a lot of projects” with essentially the same deploymentprocess (and no way to template them) -OR- utilize step skipping.
If the “Deployment Targets” field under Advanced Settings during a deployment had the capacity to filter on Roles like ad hoc tasks, this would probably fill the gap for us. Though, the capacity to enforce it like a prompted variable would be even more of a wish.