Variable embedded in Nuget Package Id in Package Deployment Step not expanded in 3.2.6

Greetings -

I’m using the variable selection entry to add an embedded variable to the “Nuget Package Id” field in a Package Deploy step. The variable is entered in the projects “Variable” section. This appears similar to the issue closed here: but it does not appear to work in 3.2.6. I can select the variable from the dropdown, and the #{} tokens appear, but the expansion does not occur when running a release via the TeamCity octo plugin. Is this a bug or is it just not supported? (It was not clear after following the github issue thread.) If it is not supported, why does the UI allow me to select a variable?

The specific error that appears in the TC build log is:

[Failed: Acquire packages] Downloading NuGet package Web.#{WebPackageId} 1.4.1220 from feed: <....>`

Hi Rory,

Thanks for getting in touch! The specific ticket that you linked to was not able to be resolved, as one of Paul’s comments mention we cannot know about environments at the TeamCity level to expand the variables. So does your variable rely on scoping at all? When you ask about the UI are you referring to Octopus or TeamCity?

One of the reasons variables are used for packaging was to solve a problem that the channels feature was specifically designed for, and I wonder if now the solution would be to create multiple channels instead. Have you considered this? Or is your scenario a bit more complicated that I am assuming?


Thanks, Vanessa -

Paul’s reply is what has me confused. Specifically, the post is about a variable containing the environment name, and then he goes on to describe creating a variable, which I have done. Given that the UI allows the selection of the variable, it’s not clear whether it will or will not have a value when the release is created. My situation is the same as the issue, however: packages having different IDs depending on the environment the release is targeting. Why is this impossible? It would seem possible if a release defers providing a value for variables until deployed to the environment at which point they are bound. Perhaps this is what channels solves?

Also, to clarify, the UI variable selection is via the Octopus web. TeamCity isn’t much of an actor here, and shouldn’t play into the problem inasmuch as it appears to just create the release - the variable and the expansion should happen on the Octo server.

Hi Rory,

Okay ignoring some of the things I said before. I think the confusion and issue here is scoping. Could you send me a screenshot of the variable/s you have for the project, and where it is defined in the step. The original ticket had an issue with not having a default value for the variable, only scoped values.

When a release is created it has only a very small number of variables available. When the deployment starts most are then evaluated based on the deployment scope.
Interestingly are you using create-release with the deploy-to flag, or create-release then deploy-release.
Seeing the command (or full build log) would also help here I think.

There was a comment at the end of the thread you linked about if a packageversion was defined it would work otherwise it wouldn’t so there could be something there also.

Let me know what you find


This is during create-release without the deploy-to flag. The deploy is invoked separately after all releases are created. The variable is defined directly in the project.

Hi Rory,

So based on the variables you have sshown, and Pauls original comment, both of your defined variables are scoped. You are asking a release which has no concept of an environment to expand a variable it doesn’t have access to. If you add another variable for IsServPackageId set to the debug variable and gave it no scope it would have a variable to work with. But again, at release, a release doesn’t have an environment, only a deployment does. So create-release can’t expand that without an unscoped variable as a holder.

I don’t know if I am explaining this well enough.


Hi Vanessa -

Yes, I think I understand that a ‘scoped’ variable is a variable with a conditional value depending on the environment in the case of a deployment. However, as the term is used in the UI, it also applies to a project-as-scope, and project is a release concept, so I’m not sure that the understanding that a scoped variable is a deploy-time-only variable is correct. Maybe there’s 2 categories of scope: release-time-scope (e.g. scopes decidable at create-release time) and deploy-time-scope (scopes only decidable when a release deployed to an environment).

If this is all the case, I’d implore you again to reconsider showing all these variables as of one kind by treating them identically in the UI. It’s easy to use the UI itself to create an invalid deployment, regardless of how strongly and frequently the documentation tries to guide the hapless user correctly. For example, if Octopus knows a variable is deploy-time scoped, it could filter it out of lists like this one where only release-time scoped or unscoped variables are allowed. This would help us users with an inability to read and follow documentation to discover success and not fall into failure.