Octo.exe create-release with package version using variables

(Robert Livermore) #1

Attempting to automate releases using Octo.exe CLI. Currently I manually create release using Octopus Deploy Project “Create Release” button. The “Create Release” form has section called packages with the option to “Enter a specific version” Text control allows the use to specify compound string value which can contain Octopus Deploy variable and variable condition

This example works

9.0.0-runtime-#{ProjectVariable}

However when I attempt to translate this to the Octo.exe CLI, it errors With "The version portion of the package constraint ‘Run Grafana:6.6.1-nanoserver-#{Docker_WindowsVersion}’ is not a valid semantic version number."

Example

docker run octopusdeploy/octo:latest-nanoserver create-release --apiKey=API-00000000000000000000000000 --server=https://ods.mycompany.com/ --project=Docker_Run_Grafana --version 6.6.1beta --package="GrafanaPackage:9.0.10" --package="Run Grafana:6.6.1-nanoserver-#{Docker_WindowsVersion}" --ignoreexisting --whatif
(Michael Richardson) #3

Hey Robert,

To be honest, using a variable in a package version is not a supported scenario. We were actually a little surprised that it worked via the web portal.

Were you intending to vary the value of the #{Docker_WindowsVersion} for different scopes (environments, channels, machines, etc)? Could you explain your scenario a little further?

(Robert Livermore) #4

Michael, thank you for your response.

###Reason why variables are needed in Octopus.Action.Package.***

We have an on-premise installation of Octopus Server since version 2.x, upgrade to current LTS (very happy with the product). We have tentacles which cross NAT networks; hence the perimeter networks result in public/private naming problem. The naming problem repeats in the use of docker private/public docker registries. (We do not want developer docker images publicly accessible, hence use a private registry). Given root docker window images are tagged by OS build and the our build binaries run all the docker build should be a Octopus parameter. The Package.NuGetFeedId , Package.NuGetPackageId, and Package.NuGetPackageVersion variables can take on compound values to adjust for the naming difference. The Octopus values are set up a project variables with multiple values with each value scoped to Machine(s): Note there is always one blank scope used as default in the multiple values.

We’ve used this setup since docker support was added.

(system) closed #5

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