Deploying specific version of Nuget package

Basically I am trying to specify the Nuget package version on a step in a process in octopus.

We have a fairly straightforward process where we use Teamcity to create a Nuget package and upload it to octopus nuget server, we then ask octopus to create a release for a given project and this fires off the Octopus process that installs 2 other nuget packages and then our new package that we just uploaded.

The problem we have is with the 2 other packages. I’ll call them PackageA and PackageB. I want to install version 1.0.0.0 of PackageA and version 2.0.0.0 of PackageB and then always the latest for the NewReleasePackage I just uploaded. The basic step of Deploy a Nuget Package has a field for “NuGet package ID” which helps me identify PackageA and PackageB. However this doesn’t let me specify a version. If I have two clients, one that uses version 1.0.0.0 of PackageA and another that uses version 8.0.0.0 then I will have two versions of PackageA in my octopus package repository and I need to be able to specify the version of the package I want installed for a given process/client. However I cant seem to find a way to do this. Can you help?

Thanks

Will

Hi Will,

Thanks for reaching out. We can definitely help! The “Octopus: Create Release” step in TeamCity is basically a wrapper for Octo.exe create-release. This command has a parameter called --package which you can use to define the exact version you want to use of the package declared in a specific Nuget deploy step. You can pass this parameter twice (one per package) on the “Additional command line arguments” field of the “create release” step.

The syntax you’ll need to add to the field goes something like this:

--package=[stepname]:1.0.0.0 --package=[stepname]:2.0.0.0

The 3rd package will resolve to the latest version if you dont declare it using --package

See the docs for all the available parameters you can pass on that field -> http://docs.octopusdeploy.com/display/OD/Creating+releases

Hope that helps!

Dalmiro

Hi Dalmiro,

Thanks for the reply. This isnt quite what I was after. You see in our process, we have 3 steps. The first two steps install packages 1 & 2 which have the specific versions. Then in step 3 we install the latest version of the recently uploaded package. In each of these steps we have to identify the package we want to install via its ID. It seems to me that the version should be specified here also (unless empty, in which case its latest). It seems odd that I would specify the ID in one system and the version in another. Does that make sense?

Thanks

Will

Also, I tried this, using both the syntax you gave me and the syntax I saw in the supplied link. When I used the syntax you gave me, I didnt get an error, but it didnt work either.

When I used the syntax given in the link below I got the following error.

Unrecognized command arguments: --package InstallVanillaPackageA:1.0.111123

I tell a lie, I just tried this and it worked.

–package=InstallVanillaPackageA:1.0.111123

previously I had spaces, so it was the below and it didn’t work
–package=[Install Vanilla PackageA]:1.0.111123

1 Like

Apologies for my not-so-clear example! Glad to hear you solved it :slight_smile:

Dalmiro

Hi Dalmiro.

I still don’t feel like this is solved. Is this the only way to specify the package version? It feels hacky to me. I dont understand why I specify the package ID in octopus but the package version in TC. Octopus talks about how deploying a Nuget package is one of the most common steps in octopus, but how do you specify the version of that package at the step level in Octopus?

When you create a release from TC you give it a version number and it seems this version number is used for all the packages in the release. If this version number doesn’t resolve then the latest version for each package is used. This just feels wrong. It seems perfectly normal to me that you would create a release comprised of multiple packages which have varying versions which aren’t the latest. If you have to specify the version in the release creation, and therefore via TC (in this case) why not specify the Nuget ID as well, at at least then have the details for packages in one place, rather than spread across 2 systems?

Is there a way to extend the Deploy nuget package step? Or can I get the source for this step so I can make my own that will allow this functionality?

I’ve looked at the source around this on github. I’m wondering If I could extend the CreateRelease command. I would change it so that when it looked to the steps in a process to gather the nuget packages and resolve the versions, it would also look for another setting, package version. If this was specified it would be this version it would use and not the latest. However I feel like this is something octopus should/does do already. Its quite basic. Maybe I’m not understanding the product well enough?

WDH,
If you need to deploy 2 versions of the same package to different clients you need to create different releases for each of the clients.
If you need to deploy 3 packages, 2 of them with set version and third with the latest available then you use command:
–package=[stepname1]:1.0.0.0 --package=[stepname2]:2.0.0.0 --package=[stepname3]

Thanks Rod, but this doesn’t answer my concern

WDH,
Idea with deployments via Octopus as far as I understand is to create a release record with package versions you want to deploy. You don’t normally change that release and package versions in it on the fly if you decided to deploy it to another client that needs different versions of the packages, you create a different release record.
You might want to explain what you want to achieve again if that does not help.

Thats not really what I’m getting at. I’ll make up a scenario so as to illuminate the issue.

Lets say we develop umbraco sites, lets say we have two clients, microsoft and google and we do work on their websites. Microsoft uses version 4.3.2 of umbraco and google uses 6.5.2 (I made those versions up). Obviously the work for microsoft and google are two seperate projects. When someone checks in code for the microsoft project, we want to build that code, make a nuget package out of it and deploy it to our testing server. To do this, we create a package that we upload to the nuget server built into octopus. The process in octopus for microsoft says deploy a vanilla version of umbraco 4.3.2 (using a nuget package) and then deploy our new code over the top. The version for the new code will be ever incrementing, so version 1.0.0.1 then 1.0.0.2 etc etc.

Then when someone does the same for google we have basically the same process, though of course its a different process, and this uses version 6.5.2 of umbraco. This means that in the nuget server used by ocotpus we have an entry called Umbraco with two versions 4.3.2 and 6.5.2. However now we have a problem because unless you specify the version of umbraco you want to use it will use the latest, 6.5.2, which isnt what microsoft has. So we have to specify the version of umbraco back in TC where we built the release. I dont think it should work like that, but before we even get there, I dont understand why we specify the nuget package ID in octopus (Umbraco) but the version in TC. I can see why you might want to in some circumstances, but circumstances like this it would make sense to put the version in octopus. My biggest issue here is that the Nuget package ID is on one system and the version is in another. Does that make sense? That’s the point I’ve been trying to get across.

WHD,
So first of all you have a solution for your issue, which is to specify the package version during TC build and release creation, right?
Another thing is that you would like to have an option in Octopus to specify default version of the package to be used for deployment?
Make sense to me as another user of Octopus, sounds useful . Dalmiro, is it something you guys can implement?

Rod,

Well depends on what you call a “solution” really :slight_smile:

But i have a way to do it now, yes. Feels more like a workaround/hack to me.

Yes, I think the step “Deploy a Nuget package” should allow you to specify the version, and if not specified then get the latest/the one specified in the call to octo.exe is used. I was quite surprised this didn’t already exist. It seems really obvious. I figured there might be something you can do with the parameters that can be passed to a step, but I have been unable to get anything using this approach

wdh,
Understood. Now let’s hear from the official support :slight_smile:

P.S. Also, I am having trouble passing a Step name that contains a space. Tried quotes and everything, Octo does not like it:
octo.exe create-release --package=‘Stop AppPools’:1.1.0001.10229
The package argument '‘Stop’ does not use expected format of : {PackageId}:{Version}

Hi whd and Rod

Apologies for the delay on my reply. I wanted to discuss this topic with the team first to make sure I was giving you the right answer.

In Octopus 3.2 we will be releasing a new feature called “Channels”, which will be (in a nutshell) very similar to the concept of “branches”. This will allow users to have multiple “channels” per project, which can be customized to use different lifecycles and NuGet package rules. This last part would be particularly interesting to you, as it’ll allow you to hardcode a version range for a specific package. In your case you’ll be able to create a setup that goes like this:

  • For step “Deploy Vanilla1” only use the nuget package Vanilla1 from version ranges 1.0.0 to 1.0.0
  • For step “Deploy Vanilla2” only use the nuget package Vanilla2 from version ranges 1.0.0 to 1.0.0
  • For step “Deploy MyApp” only use the nuget package MyApp from version ranges * to *

See attached screenshot for a visual reference.

We are planning on releasing the first open beta for 3.2 next week, and the final release 2-3 weeks after that. Stay tuned to our blog and this pinned thread in our forum for all updates related to this release.

Hopefully this is much closer to the answer you were looking for :slight_smile:

Rod - About your problem with the command, could you you paste the full command, the error and a screenshot of the step that shows its full name?

Thanks

Dalmiro

Hi Dalmiro,
3.2 looks good.

About my error, the information I provided before should be enough to replicate it. Did you try? Here is more log from TC if that helps (wdh, sorry if my blurb hijacks the topic, let me know if it is, I will move away :):

[13:28:22] :		 [Octopus Deploy] Running command:   octo.exe create-release --server http://server:10081/ --apikey SECRET --project PROJECTNAME --enableservicemessages --version 1.1.0001.10228 --packageversion 1.1.0001.10228 --package='Stop AppPools':1.1.0001.10229 --package='Stop Services on Web Server':1.1.0001.10211 --package='Stop Services on App Server':1.1.0001.10211
[13:28:22] :		 [Octopus Deploy] Creating Octopus Deploy release
[13:28:22] :		 [Octopus Deploy] Octopus Deploy Command Line Tool, version 2.5.3.33
[13:28:22] :		 [Octopus Deploy] 
[13:28:23] :		 [Octopus Deploy] The package argument ''Stop' does not use expected format of : {PackageId}:{Version}
[13:28:23] :		 [Octopus Deploy] Exit code: -1
[13:28:23] :		 [Octopus Deploy] Octo.exe exit code: -1

Hi Dalmiro,

Great news, thanks for getting back to me. Also pleased to hear this new feature will be available so soon.

@Rod

No problem, curious to see the answer to that myself, I had to rename some of my steps to not have spaces in order to get the version feature to work

Hi,

Last night we released our first pre-release version of 3.2. You can find all about it on these links:

About 3.2 - https://octopus.com/blog/octopus-deploy-3.2
About “Channels” feature - https://octopus.com/blog/channels-walkthrough

For all our pre-releases, we use a different forum to track down issues and question - http://community.octopusdeploy.com/c/support

@Rod - I reproduced your scenario the best I could(see attached screenshot), and I wasn’t able to reproduce this error. All I can think of is that you are using an old version of Octo.exe (2.5.x). Could you try updating to the latest version (3.0.15 at the time)? You can download it from https://octopus.com/downloads

Regards,

Dalmiro

Hi Dalmiro,
I’m using TeamCity plugin and version of Octo there is outdated then. I tried going to the download link you provided, but getting error: Error 404 - Web app not found.

Hi,

I believe we had a downtime on the site last night (close to the time of your message). Please try again now, or try with this direct link: https://download.octopusdeploy.com/octopus-tools/3.0.18.71/OctopusTools.3.0.18.71.zip

Thanks!