Hi,
In 1.6.x we made use of the built in variable called OctopusWebSiteName.
What is the replacement for this variable in 2.0?
Thanks,
Espen Ekvang
I found a workaround for this by using the variable in IIS Home Directory setting for the process
Thanks for the follow-up; yes, that’s the correct one. We’ll make a note to document more of these.
Regards,
Nick
Hi,
we ran into this issue and consider a major problem in our scenario because we have hundreds of deployments set up in v1.6 all based on the use of OctopusWebSiteName. We recently upgraded to v2.1.3 and now our deployments don’t work because they don’t look at that variable anymore for the name of the IIS website. Is there no way to upgrade or globally fix all these deployments to work? Seems bad that such an important variable name is just not used anymore at all?
Kirk
Hi Kirk,
Yes, this was a bit of an oversight. You can fix it globally by creating a new library variable set (Configuration -> Library) that defines the old variable name mapping to the new one, e.g.:
| OctopusWebSiteName | #{Octopus.Action.Package.UpdateIisWebsiteName} |
This variable set can then be included in all the relevant projects.
Sorry about the hassle, let me know if you have any more trouble with the upgrade.
Nick
Hi Nicholas,
We ran into the same problem with our upgrade to v2.1.3 and this indeed seems to “fix” the problem. Actually it seems more a work-around than a fix, because creating a new library variable requires a new release to be created otherwise you get an error about the process having changed. Or is there another way around this? If this variable were simply included in the “Octopus 1.6 Variable Mappings” the problem would be fixed, but unfortunately no changes are allowed to that either.
Any ideas how to apply this to all existing releases that were transferred from v1.6?
Thanks,
Wouter
“can be included”? Meaning we have to do that manually for all of our 300+ projects? Is there no way to add that in mass via some backend mechanism?
at first I thought maybe you could just add that mapping to the autogenerated 1.6 mapping library, but you set it to be “frozen”. that would be perfect because then we wouldn’t have to change anything in all of projects and then next time we generate a release it would just get the mapping. any way to change that library to not be frozen? this might be an easier solution.
“can be included”? Meaning we have to do that manually for all of our 300+ projects? Is there no way to add that in mass via some backend mechanism?
Kirk Quinbar
Lead Software Architect
T 414.454.6153
Zywave
TF 855.454.6100
F 414.454.6199
www.zywave.com
Join us on Twitterhttp://twitter.com/zywave, Facebookhttp://www.facebook.com/Zywave, Google+https://plus.google.com/u/0/b/117181742152023791165/#117181742152023791165/posts and LinkedInhttp://www.linkedin.com/groups?mostPopular=&gid=146696 to continue the conversation.
Hi all,
You can go to RavenDB, and look for a VariableSet document with the ID “libraryvariablesets-legacy”, as well as “variablesets-libraryvariablesets-legacy-snapshot1”.
You can then modify the variableset directly in RavenDB (you need to do it for both documents). This way the variable will be available in the 1.6 legacy variable set.
Sorry for the inconvenience and hope this helps,
Paul
We’ll add this mapping to the 1.6 migrator in our next release:
Paul
ok I took a look in raven.
- libraryvariablesets-legacy seems to just be the top level description of the library
- variablesets-libraryvariablesets-legacy-snapshot1 is the actual variableset but there was also another one called variablesets-libraryvariablesets-legacy-snapshot1-snapshot1. do both of those need to be adjusted?
- I wasn’t sure if I could just create a new item in the array in the raven editor with the Id being a guid. I noticed at the bottom of the variableset was that setting isFrozen. I set that to true for variablesets-libraryvariablesets-legacy-snapshot1 and was able to edit the variables from the octopus UI, so I just added your suggestion from above.
| OctopusWebSiteName | #{Octopus.Action.Package.UpdateIisWebsiteName} |
after adding the variable mapping, I tried both an existing deployment and also creating a new release for a deployment and in neither case did the deployment work. it never set the IIS websitename correctly and failed. I have attached screenshots of everything.
is there something else that needs to get done?
Hi Kirk,
Yes, you’ll need to edit both the snapshots. You can copy an item from the existing array and change the values, and just change a few numbers in the GUID - it only needs to be unique for that document.
Editing from the UI won’t work because it will only modify the main variable set and none of the snapshots.
Paul
I have updated all the snapshots and it still is not working. I started thinking about the variable that you gave me to map. Is UpdateIisWebsiteName the correct property that OctopusWebSiteName should map to? that seems more like a Boolean type name? plus under the deploy process step there are two things in that section under IIS Home Directory. one is Update IIS Website and one is the actual name under “site/virtual directory”. can you double check and see if that property name should be something different?
fyi, putting #{OctopusWebSiteName} in the “site/virtual directory” textbox of the deploy process step does work, so I know this concept will work. We just need to get the automapping of 1.6 variables to work so we don’t have to do that for 300+ projects.
Hi Kirk,
Your post made me remember - you also need a variable called:
Octopus.Action.Package.UpdateIisWebsite
With a value set to True for the IIS website convention to run.
Paul
In our case under the deployment steps, the one checkbox Update IIS Website is already checked. if this is true, does UpdateIisWebsite really matter anymore? In which case im still wondering if UpdateIisWebsiteName is the correct variable to adjust? or maybe the mappings aren’t working right? is there any log or way to show what exactly a specific mapping did during a deployment?
if it does matter, can I add it to the variable libraryset for 1.6 mappings? again the whole point is that I shouldn’t have to adjust 300+ projects.
Hi Kirk,
Can you send a screenshot of what your package step looks like in 2.0? (You can send it to paul at octopusdeploy.com)
Paul
Here are screenshots of all the settings I currently have in octopus. The first one from the packagestep is exactly how it was in v1.6 and when everything worked fine. I’m assuming that something is wrong in the variable mappings code even after I added the OctopusWebSiteName mapping?
Let me know what you think…
Thanks very much for the screenshots Kirk, and sorry for the late reply.
I just realized: the instructions I gave were the wrong way around.
Long ago, we created a special variable called OctopusWebSiteName
Then we added a setting to steps that allowed you to specify the site to update, instead of using variables. This is now the “Octopus.Action.Package.UpdateIisWebsiteName” setting.
You’re currently using the OctopusWebSiteName variable. What we need to do is tell Octopus that if it wants to know Octopus.Action.Package.UpdateIisWebsiteName, it should read OctopusWebSiteName.
This means that in your library variable set, instead of:
OctopusWebSiteName = #{Octopus.Action.Package.UpdateIisWebsiteName}
It should be:
Octopus.Action.Package.UpdateIisWebsiteName = #{OctopusWebSiteName}
Can you try this to see if it fixes the issue?
Paul