I know it’s a question that has been asked a lot of times, but I couldn’t find anything that looks like a solution.
For some reason Octopus is cleaning up the bindings if the website already exists. The bindings part of the “Deploy to IIS” step is mandatory, so I can’t skip it and I’m currently trying to create a powershell workaround (export and then import the bindings after the deployment).
The thing is that I’m constantly adding new bindings (sometimes 3 - 4 times a week), so now, after I add a new binding on the server, I have to go add it in Octopus too, otherwise it will be gone on the next release. Octopus server version is v2018.6.4
Any ideas about how can I deal with this?
Thanks for getting in touch! Octopus by design will clear the bindings each time it deploys. This is designed so the Deploy to IIS step is regarded as the source of truth for any variables related to the deployment.
There has been a lot of internal discussion around this in the past but I see there is a lot of support on the relevant UserVoice suggestion. (I can see you have also commented, thanks. )
I will bring this up with the team and see if this is something we can investigate further.
The only alternative at the moment is to use a Deploy a Package step instead of the Deploy to IIS step. You will need to configure features you need but can avoid setting the bindings with each deployment.
Let me know if you have any thoughts or questions here.
I checked the “Deploy a Package” , it won’t work for me, because I need the website part of the step, but when I add it from “configure features”, the bindings are there too.
I didn’t mention it in my previous post, but this is kind of stopping me from deploying to production , on the other environments we have static bindings and everything is fine.
Anyway, I’m almost ready with the scripting workaround, but it would be nice if we can choose what to do with the bindings.
)