I seem to be stuck on a Runbook-related problem with no obvious answer.
Let’s say we have a Project X which deploys package P1 to Environments E1 & E2.
There is a need to have post-deployment actions which manipulate the disk content of a deployed release (at path c:\Octopus\Applications\TENANT\ENV\PACKAGE\VERSION).
An example of such action: changing the theme of a website by ‘swapping out’ image folder names. Another example: adding ‘app_offline.htm’ to the package folder.
It would seem that a Runbook is a perfect way to implement this. However, within the context of a Runbook, there is no access to the installation location of the most recent Release for, say, {Package P1 + Environment E2}. The output variables of the Project’s Process (including ''Output.Package.InstallationDirectoryPath) are simply not available in a Runbook.
Octopus certainly knows the newest deployed version and deployment folder paths for every combination of {Package + Environment}; how can we access the same data from within a Runbook?
You will then take that variableset ID and you can get the information you need within api/variables/variablesetidyoufoundindeployments
The pseudo-code would be:
Do an API call on api/deployments, find the one you want based on environment/space/project/etc
Store the manifestvariablesetid to a variable.
Do an API call on api/variables/$variablesetId
Parse the json for the required variables.
Please let me know if that worked for you or if you need further help.
It just seems strange that one is forced to access a chunk of Octopus’ data via REST… while executing within Octopus itself. An in-proc shortcut would be very beneficial; accessing deployment folder from a Runbook would seem a rather common use case (e.g. reading accumulated logs).
