Search code examples
azureazure-devopsoctopus-deploy

Azure devops Octopus deploy release name semver check

We are using Azure Devops with Octopus deploy. I have integrated the release steps, and release creation as well as release to first environment (Development in my case) is happening without any issue.

Issue is with subsequent releases. Release fails in Semantic Versioning check of release name.

'1.2.1023.0508-09' is not a valid version string

at Octopus.Client.Model.SemanticVersion.Parse(String value, Boolean preserveMissingComponents)

In the first stage, I am creating Octopus release, and deploying to Development environment in the same task (using Create Octopus Release task in Azure devops)

create-release "--project=<projectName>" "--releaseNumber=1.2.1023.0508-09" "--server=<serverName>" "--apiKey=***" --enableServiceMessages "--deployTo=Development" --progress "--releaseNotesFile=<path>"

This step is successful. In the next stage, I have tried 2 variations,

  • Promote Release

promote-release "--project=projectName" "--server=serverName" "--apiKey=***" "--from=Development" "--to=envName"

  • Deploy Release

deploy-release "--project=projectName" "--releaseNumber=latest" "--server=serverName" "--apiKey=***" "--deployTo=envName"

Both of them giving same error, saying release name is not a valid version string.

My confusion is, if the name is incorrect, even the first deployment should fail. If it's correct and allowed, then subsequent stage release should also succeed.

If any one has faced such a issue before, or can add in some pointers to resolve this issue, it will be very helpful.

Solution

  • Just in case if someone came here looking for solution, below are the steps I took to solve the problem,

    • For first stage (dev in my case), create a new release. If you have multiple tenants, add them. Do not forget to add Package Version. This is especially needed when you have multiple versions of artifacts getting created. I faced hard time resolving this. if you do not add PackageVersion, latest available artifact is picked.
    • For further stages, DO NOT promote release. Instead, deploy release. This way, you can pass the same release number as configured in first stage. In my case, I kept the stage name same as my environment name. So I was able to use variable for env as well. I copied this stage for 4 different environments.