For example : if I release a package with the following release number : 1.2 when I redeploy it the release number changes to 1.2_1. But when I access the release number using the command ’ $build = $OctopusParameters[“Octopus.Release.Number”]’ in a power shell script i get back 1.2 instead of 1.2_1 while redeploying.
How can I obtain the redeployment release number value?
I’m not certain that we have a way to access what you are looking for as an Octopus variable. Could you elaborate on your particular scenario and why this value is necessary in your deployment?
It looks like the variables related to package deployment are all blank. Is there a package being deployed for this particular deployment task? If so, can you share a copy of your raw task log and process JSON for this project?
I have been unsuccessful in replicating this behavior in my test environment. You mentioned “I am unable to download process json”. Are you saying that the “Download as JSON” button isn’t working for you? If that is the case, try right-clicking Download as JSON and open it in a new tab. It should bring up the full JSON in your browser that you can copy/paste into a .txt document.
Let me know if that works or if I assumed incorrectly.
It sounds like there may be some confusion regarding the behavior of the release folders that get created under Octopus.Action[STEPNAME].Output.Octopus.Action.Package.InstallationDirectoryPath vs Octopus.Tentacle.CurrentDeployment.PackageFilePath.
Octopus.Action[STEPNAME].Output.Octopus.Action.Package.InstallationDirectoryPath is where the package is extracted to after variable replacement, transformations, etc.
Octopus.Tentacle.CurrentDeployment.PackageFilePath is where the package is deposited on the tentacle BEFORE the contents are extracted.
When deploying the same version package, it isn’t necessary to iterate and create duplicates. However, changes can be made in the project such as new/different variables, transforms, and additional settings that may cause the output from the extracted package to change from one deployment release to the next. This is why you’ll see the extracted output iterate 1.0 -> 1.0_1 -> 1.0_2 and so on.
I hope this clears things up. If I have assumed incorrectly, feel free to provide additional details for further clarification and we’ll continue to work toward a resolution.