Offline Package Drop Absolute Path Issue (and Suggested Solution :-)

Legacy Uncategorised
1

Hey guys,

We are having a small issue with the offline package generated files (.cmd and .ps1). Under the current implementation, it requires the command and PowerShell files to run under the same folder that they were originally dropped in, simply because absolute paths were used to invoke the PS script, and similarly the PowerShell script assumes that the working folder is the same as the scripts folder, as per the following examples.

Please note that our suggested solution even allows the command file to run under any working folder :wink:

It would be awesome if you could take our recommendation on board, so that we can stop having to tweak the files post drop.

OPTION 1

Offline Package Drop.Fewzion.Deployments-846.cmd

Currently:

"C:\Windows\system32\WindowsPowershell\v1.0\PowerShell.exe" -ExecutionPolicy Bypass -NoLogo -NoProfile -File "\\fewzion-octopus\octopus-drops\Test-Zib-Anglo\Fewzion\12.3.8\Offline Package Drop.Fewzion.Deployments-846.ps1"

Suggested:

pushd "%~dp0"
"C:\Windows\system32\WindowsPowershell\v1.0\PowerShell.exe" -ExecutionPolicy Bypass -NoLogo -NoProfile -File "Offline Package Drop.Fewzion.Deployments-846.ps1"
popd

OPTION 2

Offline Package Drop.Fewzion.Deployments-846.cmd

Currently:

"C:\Windows\system32\WindowsPowershell\v1.0\PowerShell.exe" -ExecutionPolicy Bypass -NoLogo -NoProfile -File "\\fewzion-octopus\octopus-drops\Test-Zib-Anglo\Fewzion\12.3.8\Offline Package Drop.Fewzion.Deployments-846.ps1"

Suggested:

"C:\Windows\system32\WindowsPowershell\v1.0\PowerShell.exe" -ExecutionPolicy Bypass -NoLogo -NoProfile -File "%~dp0Offline Package Drop.Fewzion.Deployments-846.ps1"

Offline Package Drop.Fewzion.Deployments-846.ps1

Currently:

If ($Result -eq 0) {
    & "Calamari\Calamari.exe" run-script -script "Scripts\IIS AppPool - Stop.ps1" -variables "Variables\Offline Package Drop.Fewzion.IIS AppPool - Stop.variables.json" -sensitiveVariablesSalt ysJUItC0SJGYcZKW4P5f6w== -variables "Variables\Offline Package Drop.Fewzion.IIS AppPool - Stop.variables.json" -sensitiveVariablesPassword $Password 
    $Result = $LASTEXITCODE
}

Suggested:

$CurrentDir = (Split-Path -Parent $MyInvocation.MyCommand.Definition)
...
If ($Result -eq 0) {
    & "$CurrentDir\Calamari\Calamari.exe" run-script -script "$CurrentDir\Scripts\IIS AppPool - Stop.ps1" -variables "$CurrentDir\Variables\Offline Package Drop.Fewzion.IIS AppPool - Stop.variables.json" -sensitiveVariablesSalt ysJUItC0SJGYcZKW4P5f6w== -variables "$CurrentDir\Variables\Offline Package Drop.Fewzion.IIS AppPool - Stop.variables.json" -sensitiveVariablesPassword $Password 
    $Result = $LASTEXITCODE
}

PS, also, what is the point of having “dynamic” names for the command and PowerShell files? It seams to just make them harder to use them.

2

Hi Alex,

Thanks for getting in touch!

That seems like a reasonable suggestion to us, I’ve put an issue in GitHub and we’ll look at implementing it https://github.com/OctopusDeploy/Issues/issues/1951

Regards

Damian

3

Hi Damian,

Thanks for the prompt response, that is great!

Any thoughts on the foot note questions?
what is the point of having “dynamic” names for the command and PowerShell files? It seams to just make it harder to use them.

Cheers, Alex

4

Hi Alex

It’s a deployment ID so distinguish it from a previous one and reduce human error. The idea of this feature was for when customers wanted to manually take a package into an environment and deploy it.

I’m assuming you’re trying to automate this process, which we already have support for with Tentacles :slight_smile:

Hope that makes sense

Damian

5

Hi Damian,

Thanks for the prompt response once again!

I see your point. You are absolutely spot on about us automating… we are packaging the generated files into a single file and uploading it to AWS so that our customers that can’t run Tentacles because of the lack of proxy support, can still get the same awesome benefits of scripted deployments.

I would have thought that packaging the generated files would be a typical use case, because working with hundreds of individual files would be inconvenient when it comes to moving them around. Don’t get me wrong, it is the way to go to get access the to individual files, so that we can tweak things (as per the original message), but there after I suspect that a single file is the most convenient state, until the time of installation.

Very low priority request, but perhaps allowing the name to be set in the Deployment Target setting, by either a constant or a variable, would be the way to go about this. Think about it, this would allow the use of the build number as part of the file names, and all sorts of things (obviously we are after a contact name).

We’ll keep going, assuming that this isn’t going to change soon, but it would be helpful to see it one day.

Cheers, Alex

6

Hi Alex,

It’s a tricky balance between allowing different scenarios and having so many textboxes and options that it’s more work than writing a script.
I imagine that for scenarios like yours a relay / proxy tentacle option is still the best one, and it’s on our radar.

Damian

7

Hi Damian,

Agreed 100%, we face the same challenges with our own product :wink:

Have a great weekend! We’ll keep on enjoying the OD 3, it is a masterpiece!

Cheers, Alex

8

Hi Alex,
Since this ticket was opened the offline drop scripts have been updated to use relative path names so you should be able to copy the folder anywhere and still execute successfully. That being said the working directory will still need to be in the root of the offline drop folder. Several parts of calamari work assuming the current working directory is the drop folder itself but hopefully the current behavior should meet your needs without too much problems.
Let us know if you are still having issues with the scripts and we can consider further work.
Thanks for dropping a line.
Cheers,
Rob

9

Awesome, thanks Rob!