I realize there is an easy workaround to this, but I wanted to bring it up anyhow as I thought it was odd and something that probably shouldn’t require a workaround.
That being said if you have to projects say: ‘MyProject - A’ and ‘MyProject - B’ and they both use ‘MyProject’ package to deploy and are both deployed as Windows services ‘MyProject.A’ and ‘MyProject.B’, when this package is installed it is installed in the same location for both projects by the default from Octopus. So if I have Configuration file changes that differ between ‘MyProject - A’ and ‘MyProject - B’, whoever ran last with the same version is effectively overwriting whoever was there first and both processes will run the same files if they are both on the same version and same machine.
It’s easy enough to work around this using Custom Install location, but it just seemed odd to me to be the default behavior. Perhaps there is good reason the Project Id is not used.
Thanks for getting in touch!
So I am going to use those dreaded words: It’s working as intended.
I know, I know, I’m sorry, it had to be said.
Why is it working as intended? Let me give the lamest answer, because in the legacy of the code and process that’s how it was coded.
Also, equally lame, it works for X many users. But for those it doesn’t work the Custom Install Directory feature was added.
Its not a work around, its an option.
I know, this answer sucks.
However. Did you know that if both projects were in different environments they wouldn’t write to the same directory even on the same tentacle.
Also you can make a completely dynamic custom install directory path using Octopus system variables such as:
I have done the different environments when installing the same web application to multiple sites on the same machine and I didn’t even think of that and it would probably work better for the context I was using it in anyways.
Thanks for the explanation.