When I create an Octopus release using octo.exe and pass in for example “–variable=BranchType:Release” it does not find
the latest NuGet package for that package name see attached nuget.PNG. Instead it finds the latest nuget package version for the default value of the variable BranchType which is “dev” see attached dev-var.PNG.
I was hoping that passing in “–variable=BranchType:Release” would overwrite that default value so it would treat it like see attached rel-var.PNG
I did find a work around that works with “–variable=BranchType:Release” which is to use something like “–package StepA:1.0.2” to point to the latest version of each nuget package. The problem is there are many steps that I
would have to manually update for each build and I would also need to create a script to look for the latest version number for each package.
We are aware of a current issue with octo.exe incorrectly setting prompted variables. It looks like this is what’s biting you.
The workaround at the moment is to set the label for that variable to the same as its name, or change the argument to refer to the label rather than the variable name.
I don’t think this is the same issue. I’m already setting the label for the variable to the same as its name. When I pass in “–variable=BranchType:Release” to octo.exe it still finds the wrong NuGet package version when it runs “Resolving NuGet package versions” it finds the version for BranchType:dev which is the default.
When I go to the release to see the snapshot of the variables it shows the BranchType of dev see attached show-var.PNG. But when Octopus actually runs the deployment steps it is looking for the correct NuGet package test.Release but using the wrong version which is the latest version for test.dev
You’re absolutely right - it does seem to be a different problem. Are you able to send me the complete set of arguments you’re sending to octo.exe?
I think what’s going on is that variables are resolved for a Deployment rather than for a Release. If you’re just creating a release, the variable you pass will be ignored (unless you’re also deploying - see below). If you subsequently deploy that release, that’s when you’ll need to supply the prompted variable - or it will revert to the default value. It’s different for specifying packages, because they should be consistent for a release regardless of where it’s deployed to.
The create-release command does give you the option to deploy to an environment with the additional --deployto option. If there’s a deployment, the variables passed in will be used for that deployment. However, each deployment expects a new set of variables - either already defined and optionally scoped, or prompted for each deployment.
You’re not the only person who’s been tripped up by this (twoexamples). We’re going to have a discussion internally about how it all works to make it a bit clearer what’s happening.
This is what I am passing in
octo.exe create-release --project “test” --version “15.1.0.4” --server http://***** --apiKey ******** --deployto=Development --progress --variable=BranchType:Release
I even tried separating the deploy out and I get the same result
octo.exe create-release --project “test” --version “15.1.0.4” --server http://***** --apiKey ******** --progress --variable=BranchType:Release
octo.exe deploy-release --project “test” --version “15.1.0.4” --server http://***** --apiKey ******** --deployto=Development --progress --variable=BranchType:Release
Thanks for that info. I’m pretty clear on what’s happening now, so I’ll try to explain as best I can.
The release creation and the deployment creation stages are handled completely independently. When a new Release is created, we take a snapshot of all the variables, but at that stage we don’t evaluate the value of any prompted variable. That’s because they will have to be supplied for each deployment. To simplify - we store a copy of exactly what you see when you go to the Variables tab for a project.
In your case, the --variable=BranchType:Release argument effectively gets ignored until the deployment of your new release. When the Release is created, Octopus will look for the latest version of the test.Dev package because it only knows the default BranchType value, so will find a different latest version. That version gets stored as part of the Release object so we know which version of the package to use for that step. Normally this works well, but because you’re using variable values to decide which nuget packages to use, the version evaluation will be wrong.
Unfortunately, the only way to do what you want at the moment is to use the --package argument to define the version you want to use.
We absolutely see the need for more control of variables at Release creation time and we will address it after the 3.0 release.
I’m looking forward to the 3.0 release. For a quick fix I pulled down the source for Octo.exe and added an “update-project” command to update the variable in the project.
