I have multi tenancy application which hosts number of tenants under IIS.
There’s core project that install app and then there’s project per tenant that handles tenant variables.
In tenant project I need to know where core project was installed so I can start certain executable from there and setup tenant specific stuff for that release.
One solution would be that I would use fixed installation folder, but I really like the way default step does it ie new release goes to new folder.
I tried to check octo.exe and Octopus.Client for this kind of functionality but havent yet found it…
Thanks for reaching out. Unfortunately its not possible to access that dynamic variable of a previous deployment’s process. But there are a couple of alternatives:
Using a fixed path was the first thing that came to my mind, yeah. I’d also use a Variables Library so multiple projects process’ have access to its values.
Print on a file the path where the core project was installed and then read that when deploying the tenant. There’s a variable called $OctopusParameters[‘Octopus.Action[DeployStepName].Output.Package.InstallationDirectoryPath’] that holds this value
Have a fixed parent path for the core project like C:\Apps\CoreProject and have each version be deployed on that path on a new folder with the version name like C:\Apps\CoreProject\1.0.0. That way it’ll be easy to just find the latest on the parent path when deploying the tenant by using a bit of Powershell. Actually this is very similar to what Octopus does by default: On a default install the packages will be installed on C:\Octopus\Applications[environment name][Package id][Package version]
Hope some of these ideas help you out.
Thanks for the tips, I’m gonna use them for sure.
I explored more deeply Octopus.Client-lib and found “almost” the right way, but I ended up to ask this information from IIS after all. Project A installed app and Project B,C,D asked from IIS physical path of app. All those projects use same Variable Library where webSiteName/rootFolder resides.
Using IIS’ info sounds like a good and robust enough approach