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
Ex:
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. 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:
Ex:
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.