We are going to implement this soon. To track progress subscribe to https://github.com/OctopusDeploy/Issues/issues/4159
The Workers (https://github.com/OctopusDeploy/Issues/issues/4158) feature is related and covers some of the use cases described in the comments.
Our scenario is:
1. We use a service account on the Octopus Server that is essentially neutered. It can't do much beyond communicate with Tentacle Instances.
2. Tentacle Service Accounts are constrained to doing what they need to in their own environments. I.E., environments have their own tentacle service accounts.
Given these criteria I may need to place a file in a specific network location, or run a SQL script. I only want this to happen once but the Octopus Server will not have rights to do either of these things as it doesn't operate "in the environment."
The need is for one of the deployment agents to handle this but for it to only happen once (avoiding things like database deadlocks).
The use case for us is that we have octopus packages that contain msi's to be deployed to several workstations. We also need to copy the msi's to a network share. We routinely get failed deployments due to multiple tentacles attempting to copy the msi to the network share even though we check for the existence of the file first. Ideally, we'd be able to specify that a step should only run on one of the available tentacles. I can see how this would be useful for database migrators or other "do once and forget" jobs.
It would allow for custom code to verify that all variables are resolved for the target environment/role prior to a deployment.
Let groups be hierarchical and participate in scoping.
E.g. a variable scoped to a group called "uat" would apply to "uat1","uat2","uat3", etc.
In my opinion:
Ideally metadata would be in two forms: name value pairs and tags.
The usage would be both for display purposes & for querying environments/machines to do work on.
Or at least make it an option using Octopus system variables.