Offline deployment access other step variables

Hi
I am having issues with offline deployment.
I have a step which is a custom PS script. It has a parameter of type “A previous deployment step name”. In the script I am using it :
Octopus.Action[PreviousDeploymentStepName].Output.Package.InstallationDirectoryPath

And the issue is that that variable doesnt exist in variable.json for my current step. So it cant resolve it and deployment step fails cuz it couldnt find files from previous deployment step.

Not sure if thats a bug or something I did wrong?

Thanks
Maciej.

Hi Maciej,

Thanks for reaching out. Could you please export the custom step as JSON and send it to us? I wanna see if I can reproduce this.

Thanks,

Dalmiro

We are using this template from library as base for our script:
https://library.octopusdeploy.com/#!/step-template/actiontemplate-sql-deploy-dacpac

The issue is on this line :
$installDirPathKey = ‘Octopus.Action[{0}].Output.Package.InstallationDirectoryPath’ -f $dacpacPackageStepName
$installDirPath = $OctopusParameters[$installDirPathKey]

Note that it working fine with tentacle deployments, only offline drop fails.

Hi,

Which Octopus version are you running? If you are not running the latest, I’d recommend you to upgrade your server and try it again. I just tested this on my end running 3.2.3 and it seems to work ok.

If that doesn’t help, please send us a copy of one of your offline packages so we can check it ourselves.

Thanks!

Dalmiro

In case you want to test the same thing I did, this is the step template I used:

{
  "Id": "ActionTemplates-181",
  "Name": "TestTemplate",
  "Description": null,
  "ActionType": "Octopus.Script",
  "Version": 4,
  "Properties": {
    "Octopus.Action.Script.Syntax": "PowerShell",
    "Octopus.Action.Script.ScriptBody": "write-output \"The name of the step is [ #{StepName} ]\""
  },
  "SensitiveProperties": {},
  "Parameters": [
    {
      "Name": "StepName",
      "Label": "StepName",
      "HelpText": null,
      "DefaultValue": null,
      "DisplaySettings": {
        "Octopus.ControlType": "StepName"
      }
    }
  ],
  "$Meta": {
    "ExportedAt": "2015-11-18T18:05:55.177Z",
    "OctopusVersion": "3.2.3",
    "Type": "ActionTemplate"
  }
}

All it does it print on the screen the name of the step selected on the dropdown.

We are using 3.2.0, probably should have mentioned it in first post :slight_smile:
I will look into upgrading and let you know if it works or not.

Thank you.

Hey,
So we upgraded to 3.2.4. And the same error occurs.

I even used the this script:
https://library.octopusdeploy.com/#!/step-template/actiontemplate-sql-deploy-dacpac
Instead of our custom one, and it also has this error.

So again just to recap both of those scripts have following lines :

Set .NET CurrentDirectory to package installation path

$installDirPathKey = ‘Octopus.Action[{0}].Output.Package.InstallationDirectoryPath’ -f $dacpacPackageStepName
$installDirPath = $OctopusParameters[$installDirPathKey] + ‘\content’

I added output for those variables and it evaluates to
$installDirPathKey = “Octopus.Action[Deploy DACPAC NuGet Package - Local].Output.Package.InstallationDirectoryPath”
$installDirPath = “\content”
$OctopusParameters[$installDirPathKey] = “” <- this is the issue.

Script that you shared is checking for step name, and that’s working correctly it just doesn’t contain variable for “output.Package.InstallDirectoryPath” for that step (apparently non of the output variables are available in offline deployment)

Any more ideas on the issue?

One more thing, When I added variable
Octopus.Action[Deploy DACPAC NuGet Package - Local].Output.Package.InstallationDirectoryPath = "d:\Octopus\Env\1.1.1.1\DACPAC NuGet Package - Local"
to variables (json file) for this step it all worked fine. So the only issue is missing variable or some way of getting it.

Any news on the fix?

Hi,

Sorry for the delay. I’ve tried to reproduce this on my end using that same Step Template you were using in 2.3.6, but it is still working as expected on my end.

Could you please send me the full unmodified offline package that Octopus is producing? If possible, modify the deployment process so it only has 2 steps: The deploy step and the step that uses the name of the previous step.

Regards,

Dalmiro

Hey,
I created a sample package which has the same error. Can you provide me with email to send it to?

Maciej.

Hi Maciej,

You can either set this conversation as Private and attach it on your reply (preferred if the package is small), or you can upload it here: https://file.ac/CIqRKnT8b6w/

Thanks,

Dalmiro

Uploaded.

Hi Maciej,

Thanks a lot for the sending the package and for the patience. I was able to reproduce this and submitted a github issue for it: https://github.com/OctopusDeploy/Issues/issues/2208

Dalmiro

Thank you for submitting it. I see its marked as wontfix and we really need this.

Is there any way you might think of that we can use to mitigate this issue? Because in variables its also missing version so I can’t construct the path my self.

Maciej.

Hi Maciej,

It seems I went a bit ahead of myself when creating that github issue. The fact that output variables cannot be used in Offline deployments was a known issue that I totally overlooked. Please accept my apologies for this.

I’ve been thinking about a workaround and I came to a simple enough to implement solution:

The problem:The variable that holds the path where the package was extracted is only available during the NuGet deploy step.

Solution:Use that variable in a script on the Nuget deploy step, and send its value to a txt file that can be read by subsecuent steps.

Setup

  1. Create a variable in your project called textFilePath and assign it a path value like C:\Temp. You’ll see where we’ll be using it in a sec

  2. On your nuget deploy step, enable the Custom Deployment Scripts feature and add the following script as a Deployment script. See attached screenshot

#making sure the path exists
if(!(test-path $textfilepath)){
    "$textFilePath does not exist. Creating it..."
    new-item $textFilePath -itemtype Directory -verbose
}

#During the deployment step, the variable CustomInstallationDirectory holds the path where the package will be deployed, which is what you want to use from another step
#The below line copies that path to a txt file with the format $textFilePath\[name of the nuget deploy step]
$OctopusParameters['Octopus.Action.Package.CustomInstallationDirectory'] | out-file  "$textfilePath\$($OctopusParameters['Octopus.Step.Name']).txt" -verbose -force

This script will create txt file on the path set for $textFilePath with the same name as the deploy step. If you set the path to C:\temp and the deploy step name is Deploy My Package the final path would be C:\Temp\Deploy My Package.txt

  1. Modify the step template to get the content of the txt file created in (1) using the value of the variable textFilePath and name of the step from the dropdown parameter. The below snippet is what I used inside of my test step template
$dacpacPackageStepName = $OctopusParameters['DacpacPackageStepName']

#InstallDirPath will hold the path where the package was deployed.
$installDirPath = get-content "$textFilePath\$dacpacPackageStepName.txt" -verbose

write-host "The name of the deployment step is : $dacpacPackageStepName"
write-host "The path were the package was installed was: $installDirPath"

Let me know if this makes sense and works for you.

Dalmiro

FYI - We have a uservoice suggestion to add Output variables to offline deployments. Try to drop by and put some votes on it if you’d like to see this implemented in future versions

Hi,
Since 3.3.0 is almost out, this feature is planned to be included?
In the blog post there is no reference to updates at Calamari level, however in Github there is activity regarding the Calamari.

Thanks

Hi Joao,

Unfortunately that feature is still just a suggestion, and its not in our immediate 3.3 plans to implement it. Its still open for vote though cause we might consider get back to it in the future.

Thanks
Dalmiro

Hi,
Thanks for the clarification. Any change to the community sort this out?
There are some ideas around it, and in our case is a showstopper. To
workaround this, the deployment process is clumsy and have more steps than
it should.

Regards João Rosa

A ter, 16/02/2016, 21:42, Dalmiro Grañas tender2+d24b646f4a@tenderapp.com
escreveu: