Octopus.Action.Package.NuGetPackageId No Longer Resolves

As of 3.4 when the system variable Octopus.Action.Package.NuGetPackageId is used, the following status is given:
Parsing file ‘D:\Deployments\Environment\Application\Version\App.config’ with Octostache returned the following error: The following tokens were unable to be evaluated: '#{Octopus.Action.Package.NuGetPackageId}'

Hi Peter,

Thanks for reaching out. Can you follow the below steps and send us a full deployment log?

1) Add these 2 variables to your project http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables

2) Create a new release (so the new variables take effect) and deploy it. If possible skip as many steps as you can and only leave step we are troubleshooting in order to avoid the noise in the log.

3) Send us the raw log of that deployment http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task

Thanks!
Dalmiro

Hi Dalmiro,
I’ve attached the log file.

Thanks,
Peter

ServerTasks-19024.log.txt (137 KB)

Hi Peter,
Thanks for getting in touch, I’m sorry to hear that you are experiencing some issues with the latest build. We have begun a process to deprecate the Octopus.Action.Package.NuGetPackageId variables to replace them with the more generic Octopus.Action.Package.PackageId variables to better support other, non NuGet-based deployments. That being said as part of the change we intended all the old ..Package.NuGet.. variables to still get set in order to provide backwards compatibility. It appears that there may be somewhere that we have missed.

To get to the bottom of this issue and ensure we can prevent anyone else having the problem could I get a little extra information. First of all thanks for sending through the logs. We can see that the new values (e.g search for Octopus.Action.Package.PackageId or Octopus.Action.Package.FeedId) are being set, along with the old action-indexed variables (e.g. Octopus.Action[Deploy-CADPublishers].Package.NuGetPackageId) however the non-indexed values for some reason are not getting added.
Could you confirm how the step is set up? Is it a step template or library template that has been imported? Have you updated the template since the import?
For a test, could I get you to manually set the Octopus.Action.Package.NuGetPackageId variable on the project itself and set it to #{Octopus.Action.Package.PackageId} and see if that then sets the value. This is obviously not a fix, but might help clarify that something isn’t overriding or clearing the value that should be getting provided.

Thanks again for the extra information and for bringing this to our attention. Hopefully we can get your project sorted out ASAP and get the deployments flowing again.
Thanks,
Rob

HI Rob,

So this is just a standard “Deploy a Package” step using xdt Transforms in the “Configuration transforms” feature, and we fill in the variable in the Substitute variables in files feature.

Thanks,
Peter

Thanks Peter,
Could you also confirm the other question in my previous post regarding manually providing a Octopus.Action.Package.NuGetPackageId variable on the project itself and set it to #{Octopus.Action.Package.PackageId} and see if that then sets the value.
It should already be setting this value under the hood so I would be interested to see if its being cleared by something.
Cheers,
Rob

We have just updated to 3.4.1 and have also lost this highly pervasive variable value.

We have been able to manually set a new variable with the same name (#{Octopus.Action.Package.NuGetPackageId}) and that is getting us by.

Be nice if the value came back although we will already have worked around it. I am assuming that our work around won’t get broken by whatever fix you implement of course.

Regards

Brody

Hi Brody and Peter,
With some extra information from another case, I believe we have pinpointed and fixed the issue which will be available in the next release, probably later this week.
Basically the code that was providing the ability to create a variable alias for deprecated variables was only supporting a single replacement per deployment, despite in this case it potentially needing to take place for every action.
Our apologies for any inconvenience this may have caused you, hopefully you can get back on track with your deployments.
Please let us know if you encounter any further problems.
Cheers,
Rob

Hi Rob,

Sorry about that. Yes, when you update the variable it sets the value correctly.

Thanks,
Peter

We ran into this as well, it seems. Eagerly awaiting the fix!

I see it’s fixed in the latest release. Thanks!

Notice:

This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.