Variables - Overloading them

Scenario: In Octopus I was trying to set up a series of steps to build my IIS sites. There are things in the app pools and IIS sites that I want to set that aren’t covered in the existing process (and some permissions to set on folders, etc. that I don’t want to run more than once on a server), so I set up two different step templates to do this. What I then did is set defaults of #{appPoolName} (and #{siteName}, etc.) in the step template.

What I then hoped to do is create a project and create variable and scope those to an application/site. Then I thought I could set up roles of site1, site2, site3, etc. and create variables for each of those as necessary.

App1/Site1 Name: foo - Role: foo
App2/Site2 Name: bar - Role: bar

siteName foo Environment: Dev; Role: foo
appPoolName foo Environment: Dev; Role: foo
siteName bar Environment: Dev; Role: bar
appPoolName bar Environment: Dev; Role: bar

Then in the project I could set up
Create AppPool - foo (Role: foo)
Create Site - foo (Role: foo)
Create AppPool - bar (Role: bar)
Create Site - bar (Role: bar)
And accept the defaults. When I create a new set of environments, I would then just to have the roles I wanted, and run that project on the new server.

Well… having done that, it doesn’t work. :slight_smile: While I’m guessing the variables would be scoped to the role, they end up evaluating early* and so there is collision (more than one variable named AppPoolName). Aha I thought… that’s why there is the ability to restrict to steps. So I tried that. The variables still (seem to) collide.

So what I discovered is that for every variable that potentially needs a new valuable I need to create a uniquely named variable and then update the values in the custom step template:

fooSiteName foo Environment: Dev; Role: foo
fooAppPoolName foo Environment: Dev; Role: foo
barSiteName bar Environment: Dev; Role: bar
barSiteName bar Environment: Dev; Role: bar

Long way to ask this, but is that intent or am I doing something wrong?

    • Yes I realize “early” is subjective here because it is what it is, but given that I may need a variable (“AppPoolName”) more than once but restricted differently and with a different value in a project, it seems like it is done early.