I was wondering if it’s intentional that when using the octo cmd line to create a release, that using the --defaultpackageversion command overrides all --package commands that follow? Would it not make more sense to have it the other way round so if you need to specify a default version for most of your nuget packages you can still use --package to set the version of specific nuget packages.
EDIT - Scratch that I was right the first time, defaultVersion is overriding the package command.
Hi,
Thanks for reaching out. I just tested this with the latest Octopus and Octo.exe and it works as expected: --Package overrides --DefaultPackageVersion
Which version of Octo.exe and the Octopus server are you running?
Regards,
Dalmiro
Hi Dalmiro,
I’m using 2.5.6.1010 for server and 2.5.3.33 for cmdline in TeamCity. I’m planning on upgrading to the highest version of 3.0 that was available when our license expired soon.
Could it be positional? Did you have --Package before --DefaultPackageVersion in the cmd line? I have --DefaultPackageVersion before --Package and I’m using Teamcity’s create release to make the call.
Hi,
Tried in both positions, always got the same expected result.
-
Which Nuget feed are you using for this? Octopus’ built-in feed, TeamCity’s feed, another 3rd party one?
-
Are you trying to use a Nuget Package that you created on that same TC build?
Regards,
Dalmiro
I’ve setup TeamCity to create and publish Nuget Packages to Octopus’s internal feed. When creating a release I’m using the following commands in the Create Release step:
–package DeployGetSelectedWorkflowTask:6.9.4.9 --package DeployArcGISAPI:3.14 --DefaultPackageVersion %build.number%
With this, the output for all packages is:
[08:23:05][Octopus Deploy] 1 Deploy Viewer Files 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 2 Deploy ArcGIS API 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 3 Install GSAA Map Site 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 4 Deploy Custom Binaries to Rest Bin 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 5 Deploy Custom Binaries to WorkFlow Designer 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 6 Deploy GetSelectedWorkflowTask 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 7 Deploy GSAAMap WebServices 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 8 Deploy Rest Web.config 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 9 Copy External Deployment Package 6.9.5.176 User specified
[08:23:05][Octopus Deploy] 10 Copy ArcGIS API 6.9.5.176 User specified
where %build.number% has a value 6.9.5.176
Hi,
Tried reproducing this in an Octopus 2.6 instance with using TeamCity and it still works as expected on my end. Arguments position doesn’t seem to matter also as it keeps working just fine.
At this point I’m afraid that the only thing left to recommend would be to upgrade your Octopus Server. First from 2.5 to 2.6, then to 3.0. I can definitely confirm this isn’t happening in 3.x.
Sorry for the crappy news
Dalmiro
It would be interesting if you could catch the HTTP calls (using Fiddler) from your TC agent to Octopus when the deployments are triggered.If we could see the content of the POST call the /releases and /deployments, we could at least narrow down where the problem is coming from.
Was looking at this again Dalmiro and had a thought. Does the -package command work for child steps? The packages I need to be specific versions are being deployed as child steps.
Hi,
About the error you were having when running --package DeployGetSelectedWorkflowTask:6.9.4.9 --package DeployArcGIS API:3.14 --DefaultPackageVersion %build.number%
You need to put the names of the steps with spaces, just like in your deployment process. Like this:
--package "Deploy GetSelectedWorkflowTask":6.9.4.9 --package "Deploy ArcGIS API":3.14 --DefaultPackageVersion %build.number%
All credit goes to my teammate Vanessa who spotted this
Was looking at this again Dalmiro and had a thought. Does the -package command work for child steps? The packages I need to be specific versions are being deployed as child steps.
It should work, yes.
Let me know if including the spaces fixes this for you.
Regards,
Dalmiro
I get this error when using the step name in quotes with spaces:
The package argument ‘Deploy GetSelectedWorkflowTask’ does not use expected format of : {PackageId}:{Version}
I tried using the PackageId in quotes instead and got the same error. Removing the quotes is successful but gives the same outcome as though the --DefaultPackageVersion is overriding the other version commands.
I’ve upgraded to the latest version of Octopus 3 that my license is valid for.
Using this format works when not using the --DefaultPackageVersion command:
–package DeployGetSelectedWorkflowTask:6.9.4.9
HI,
-
To which version of Octopus did you upgrade?
-
After the upgrade, did you also upgrade the TeamCity plugin? This is necessary, as that plugin contains the
Octo.exeversion that matches 3.0 versions of Octopus.
Regards,
Dalmiro
Hi Dalmiro,
Sorry for the late reply. I’ve upgraded to all the tools available on the downloads page for version 3.1.4. Teamcity lists the versions it’s using as :
Octopus Deploy Command Line Tool: 2.6.3.60
Octopus Version: 3.1.4
API version: 3.0.0
Could it be the wrong version of the Octopus command line tool?
EDIT:
Just out of curiosity, I was going over your previous replies and the octo tools help docs, and noticed that what’s in the docs, doesn’t work as stated:
In help Doc:
--package=StepName [Optional] Version number to use for a package
in the release. Format:
--package=StepName:Version
But the logs in Teamcity expect the parameters for " --package" in the format: “packageID:Version”
Edit 2: I think it might be a mistake in the logging for the Teamcity plugin. I tried with the packageID and it errors because the name has a “.” in it. It also doesn’t like the Step name with spaces, wrapped in quotes or without.
Hi,
Which Octopus Version are you selecting on your Octopus TeamCity step? (see attached screenshot to know what I’m talking about).
It sounds like you are selecting the 2.0 version instead of the 3.0 one.
Dalmiro
That’s exactly it Dalmiro! However there is no option for me to select 3.0 in the drop down. Might that be because the Steps were created for 2.0?
I’m actually not sure about that last question. If you try to add a new Octopus step to your build process, does this new step (which was adde after you updated the TC plugin) come with the 3.0 option?
I managed to get it to show up 3.0 by installing a later version of the plugin than is recommended for 3.1.4. It still doesn’t change the behavior that I’m seeing with the command line options.
Hi,
I think It’ll be better if we schedule some time to walk through this one while sharing your screen. Could you pick a time from the link below? It’ll block that time on my calendar.
https://calendly.com/dalmirogranias
Best regards,
Dalmiro
Hi Dalmiro,
Sorry it’s been a few weeks, the command line arguments started working again when I used:
–package “Install GetSelectedWorkflowTask:6.9.4.9”
which is odd because I tried this before and it didn’t work. It’s working now so it’s all good.
Thanks for the help.