Set Environment During Deploy

I’ve been working on a project where we are creating generically named environments (Test001 for instance) via Chef. The issue I am facing is with the scoping of variables. We have been able to get around this so far using the generically scoped variables (no scope in this case). However, in our later environments, we’re going to need actually specify the environment to properly scope the variables.

My first thought was to create a base “Test”, "QA, and so on environment without machines and scope all the variables to those environments. Then I was going to add an initial step to set the environment based on the naming convention as such:

$OctopusParameters[“Octopus.Environment.Name”] = “Test”

This doesn’t appear to be working when I look at the variable sets in the release log. I assume this is because the variable probably get pulled before the first process step. Is there a way to accomplish such a thing?

A little background here. Again, we’re using Chef to spin up these machines. The environment, machines, and roles are all correctly being assigned, so everything looks good there. We are on an outdated version of Octopus and plan on upgrading here in the next few days. Our current version is 2.6.4.951.

MANY thanks in advance!

Hi Jerrod,

Thanks for getting in touch! What you are trying to do isn’t possible. Octopus.Environment.Name is not a variable that can be in any way modified as it is pretty critical to the deployment that is occurring.
I am glad to hear you are upgrading as with 3.4 we think we might have a solution for you. In 3.4 you could utilize Multi-Tenancy to get what you want. As with MT you can create tags that could be applied and would provide you with a solution here.
You would need a tenant but that could be simply the generic name Test and have a set scoping for tags. Then your machines would have this tag and get the correct variables scoped to them for these tenant deployments.

It is slightly hard to explain (I am not doing a good job in rushing this answer). The only other solution would be to script variable insertion when you are creating these test environments.

Let me know how your migration is going, and if you think we might be able to get a solution together for when 3.4 is released and I will try to explain it much better.

Cheers!
Vanessa