AzureDevOps and The Octopus Command Line (CLI) amends release number

When using the Octopus cli commands from within AzureDevops to create a release the release number changes. (adding an extra .0)

Extract of script call to octo.exe ( i have tried adding a lot of variables)

create-release --project 00-PROJECT --version 2021.4.0- --defaultPackageVersion 2021.4.0- --releaseNumber 2021.4.0- --ignoreChannelRules --packagePrerelease 2021.4.0- --server --apikey ****

Creating release…
Release 2021.4.0.0- created successfully!

You can see the release is now
2021.4.0.0- (when it should be)

Is our build numbering an issue?


Hi Nigel,

Thanks for getting in touch! I’m sorry to see you’re hitting this very unexpected issue! I haven’t been able to reproduce this locally, however. Would you be willing to share your build logs from AzureDevops? I’d like to check out the context around this, and it’ll also print out other helpful information such as versions of the plugin, CLI, etc. to help us better dig into this one.

Feel free to send that through to, or mark this thread as private. :slight_smile:

I look forward to hearing back!

Best regards,


Hi Kenny, thanks for the reply.

Within Azure DevOps we are using the Octopus CLI tool version embedded and calling the Octopus CLI via PowerShell. Below are the logs from the release creation.

Please note I am aware this step may have too many parameters
create-release --project 00-PROJECT --version 2021.4.0- --defaultPackageVersion 2021.4.0- --releaseNumber 2021.4.0- --ignoreChannelRules --packagePrerelease 2021.4.0- --server --apikey API-

This also occurs if we use the Azure DevOps extension (v4) and also on Octopus directly if we create a manual release. The release number changes and adds the extra .0 in the same way as the CLI.

I think its maybe our build numbering, we did amend it recently as we had an issue picking up artefacts but resolved it with help from Jeremy (see your ticket 26778 The package was not found in the feed)

Are there any logs we can extract from Octopus. As I can replicate the issue on Octopus using the UI the logs below may not be of use.


2021-06-17T23:12:29.8850302Z ##[section]Starting: octo create-release --project 00-CLONELUK 2021.4.0-
2021-06-17T23:12:29.8958927Z ==============================================================================
2021-06-17T23:12:29.8959524Z Task         : PowerShell
2021-06-17T23:12:29.8960064Z Description  : Run a PowerShell script on Linux, macOS, or Windows
2021-06-17T23:12:29.8960546Z Version      : 2.170.1
2021-06-17T23:12:29.8960997Z Author       : Microsoft Corporation
2021-06-17T23:12:29.8961591Z Help         :
2021-06-17T23:12:29.8962258Z ==============================================================================
2021-06-17T23:12:30.9097550Z Generating script.
2021-06-17T23:12:30.9566419Z ========================== Starting Command Output ===========================
2021-06-17T23:12:30.9820372Z ##[command]"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\Work-P02\_temp\c75152de-b2f4-4318-bc4f-0477d533bfdf.ps1'"
2021-06-17T23:12:31.2616667Z Build id  2021.4.0-
2021-06-17T23:12:31.2851239Z D:\Work-P02\r1\a>dotnet "D:\Work-P02\_tool\octo\7.4.4\x64\/octo.dll" create-release --project 00-CLONELUK --version 2021.4.0- --defaultPackageVersion 2021.4.0- --releaseNumber 2021.4.0- --ignoreChannelRules --packagePrerelease 2021.4.0- --server <server> --apikey API- <key>
2021-06-17T23:12:31.6588491Z Octopus Deploy Command Line Tool, version 7.4.4
2021-06-17T23:12:31.7897849Z Detected automation environment: "AzureDevOps"
2021-06-17T23:12:32.5995655Z Space name unspecified, process will run in the default space context
2021-06-17T23:12:32.6004005Z Handshaking with Octopus Server: https://octopusdeploy.laseruk.corp/
2021-06-17T23:12:32.6826801Z Handshake successful. Octopus version: 2021.1.7236; API version: 3.0.0
2021-06-17T23:12:32.8265094Z Authenticated as: AzureDevOps (a service account)
2021-06-17T23:12:32.8453903Z Found environments: 
2021-06-17T23:12:32.8569512Z This Octopus Server supports channels
2021-06-17T23:12:32.9656666Z Found project: 00-PROJECT(Projects-481)
2021-06-17T23:12:32.9705204Z Automatically selecting the best channel for this release...
2021-06-17T23:12:33.0540954Z Building a release plan for Channel 'Default'...
2021-06-17T23:12:33.0542470Z Finding deployment process...
2021-06-17T23:12:33.1577540Z Finding release template...
2021-06-17T23:12:33.3084415Z Selected the release plan for Channel 'Default' - it is a perfect match
2021-06-17T23:12:33.3094701Z Using version number provided on command-line: 2021.4.0-
2021-06-17T23:12:33.3144974Z Release plan for 00-PROJECT 2021.4.0-
2021-06-17T23:12:33.3145480Z Channel: 'Default' (this is the default channel)
2021-06-17T23:12:33.3175481Z   #   Name                                               Version                               Source           Version rules      
2021-06-17T23:12:33.3176891Z   --- -------------------------------------------------- ------------------------------------- ---------------- -------------------
2021-06-17T23:12:33.3178028Z   1   Deploy to E3 00-SA-Service    2021.4.0-   User specified   Allow any version  
2021-06-17T23:12:33.3179191Z   2   Deploy to E3 00-SA-Service    2021.4.0-   User specified   Allow any version  
2021-06-17T23:12:33.3180302Z   3   Deploy to E3 00-SA-Service    2021.4.0-   User specified   Allow any version  
2021-06-17T23:12:33.3182095Z Creating release...
2021-06-17T23:12:33.9592681Z Release **2021.4.0.0-** created successfully!
2021-06-17T23:12:33.9812931Z ##[section]Finishing: octo create-release --project 00-CLONELUK 2021.4.0-

Hi Kenny, here is some more info, which is even stranger. These are two consecutive builds… 28 then 29

2021.4.0- – Adds extra 0 on Octopus
2021.4.0- – is OK


Hi Kenny, some more info to focus on… the last part of the build ID… is I think the cause of the issue… Yu can see below. the builds with the same .96f6911c are adding the 0. the one ending 767 is ok. (Maybe we need to change this or ensure its following a pattern.


Hi Kenny, does the information above help understand the issue, or do we need to provide some more logs etc.
thanks Nigel

Hi Nigel,

I appreciate you keeping in touch, and my apologies for the delay in getting back to you over the weekend. Just letting you know here that I’ve responded to your email. In short I’m wondering if it’s somehow being affected by the Release Versioning template as defined in your project. Hopefully seeing how yours is configured will help me more accurately reproduce your setup and narrow down what could be going on.

I look forward to getting to the bottom of this one!

Best regards,


Hi Kenny

Thanks for the email.

We are using the “Use the version number from an include package” and tying this to a package step. I have not tried to specify the release version template. In all cases (even if the release number is incorrect) the correct packages are chosen.

Also to add we are using artefacts from our own hosted version of Nexus, via an external feed, not artefacts from Octopus or Azure DevOps. All works well except we get the random occurrence of the release number changing.

We use the actual release number in one of the steps later in the process so it needs to be exact, this is why I am raising the issue. I can do a work around and use the release notes field for this instead or I was looking on the documentation to see if there was a custom field (but I could not see any other than maybe the --package=VALUE Format: StepName:Version orPackageID:Version) . However this is probably not an ideal use of the release notes field.

Hi Kenny

I think it might useful if we could have a screen share session, would that be something you can accommodate. We can set up at Teams meeting at a time that suits you and walk through the issue and it might be easier to demonstrate.


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.