I am using the expression at the very bottom of the page #{Octopus.Date.Year}.#{Octopus.Date.Month}.#{Octopus.Date.Day}.i. This is working perfectly when I create a release manually in Octopus; for example today it has created 2021.04.22.2.
When I enable the automatic release creation trigger, it successfully fires when a package is uploaded to the Octopus feed, however the release version has failed to generate properly. It generates 2021.04.22.i - it hasn’t replaced the i with the incremental number.
If I push a new version of the package a second time, I get an error in the Octopus server logs:
Unable to automatically create a release for project ‘XX’ when package XX version 31 was pushed to the built in feed for space Default as the versioning strategy resulted in a release version that already exists
Presumably it’s tried to create a release with the version 2021.04.22.i, which does indeed already exist.
Could you tell me what version of Octopus Server you are currently running? I would like to recreate this in a test environment to confirm this behavior.
Jumping in here for Donny as he’s off the clock, and I’ve actually hit this issue myself in the recent past.
This is actually a current known issue that I’ll paste a link to below for you to track.
The workaround is to instead use the #{} syntax instead of i, which is because when releases are created automatically, the version resolves in a different place than where the i masking code is. This alternative is outlined in this doc section.
Sorry for the inconvenience and confusion caused here. Let us know how you go, or if you have any further questions.
Thanks very much for the prompt replies. I’ve tried using the #{} syntax from the documentation as suggested. It appears to be running, but with some expected results.
A release is triggering but it’s erroring and failing to complete.
Unable to automatically create a release for project ‘XX’ when package XX version 32 was pushed to the built in feed for space Default: The release number '2021.04.23. 0 ’ does not appear to be a valid semantic version number. The version must consist of between 1 and 4 number only parts before the optional pre-release part. e.g. 2, 2.1, 2.4.0.23, 2.4-beta and 1-beta.2
I presume it’s erroring on the whitespace before the incremental number (it’s added 3 spaces before the ‘0’). I’ve played around with the expression by removing the whitespace around the ‘0’ but it doesn’t seem to have an affect.
I’m running Octopus v2020.6 (Build 4788) if that helps.
Do you have any thoughts on why this might be happening?
Apologies, removing the whitespace around the ‘0’ in the expression DOES have the effect of removing a single whitespace character from the version number, however there are still 2 whitespace characters inserted in the version number.
