Semantic versioning not working on build 0

Octopus Server
, , ,
#1

Hi there,
We recently migrated from 2019.13.7 to 2020.6.4701. Everything appears to be working well except for versioning.

We’re using this for our versioning: #{Octopus.Date.Year}.#{Octopus.Date.Month}.#{Octopus.Date.Day}.i

Instead of working perfectly as it did in the older version of the software, we’ve noticed that the first build of the day (Where i = 0) doesn’t work, the build prints the i in the build. Once we manually change it to zero, subsequent builds that day increment normally. Any help would be appreciated.

I should also state that this is an environment that takes NuGet builds and deploys them to an IIS web server.
-Shaun

#3

Hi Shaun,

Thanks for reaching out and the information.

Is this versioning for releases or packages? Can I please get some more details on how you are creating the release/package?

Please let me know.

Best,
Jeremy

#4

It’s versioning for releases.
The packages are generated by TeamCity and pushed to the GitHub Repository.

#5

Hi Shaun,

Thanks for the information.

Can I please get the full octo command you’re using in TeamCity that’s being run to create the release that’s causing issues so I can try to reproduce it on my end? You may need to enable verbose logging in that build step to get the full command.

Best,
Jeremy

Best,
Jeremy

#6

It’s not Teamcity that creates the release, it’s being created by the Auto Release creation in the Triggers selection:
Automatic Release Creation

#7

Hi Shaun,

Thanks for keeping in touch and for your detailed report. I’ve been able to reproduce this issue where automatic release creation doesn’t resolve the increment i set in the release versioning template.

I’ve confirmed in my test that creating the release via Octo CLI create-release command does indeed resolve the i like it should, so if it’s possible to add that as a build step in TC that’d be my recommended workaround (which should work since our TC plugin simply uses the Octo CLI under the hood).

Sorry for the inconvenience we’ve caused here. Please let us know if we can help with anything going forward.

Best regards,

Kenny

#8

Hi Shaun,

Just a quick update. I raised this issue internally and turns out my report was a duplicate of a previously reported bug. Here’s the real issue to track. :slight_smile:

Best regards,

Kenny

#9

Thanks for your work Kenneth,

Meanwhile we’ll attempt the work around, any word on when this bug will be placed in a sprint to fix (Even if that means updating the built-in documentation on the page to instruct the user to use the work around)?

#10

Hey Shaun,

Let me talk to the engineers and find out if we have any more information for you. Kenny or I will get back to you as soon as we know.

Best,
Jeremy

#11

Hi Shaun,

Thanks for keeping in touch. This is currently being looked into, though unfortunately we don’t have any ETA at this stage. Other than the workarounds I originally suggested, maybe another option if you’re not wanting to modify your build process would be the following (though admittedly it’s a bit long winded).

  • Create a variable in your project (in my example it’s called CurrentDay)
  • Set the value to the variable #{Octopus.Date.Day | Replace "^0" }
  • Create another project variable (in my example it’s NextRevision)
  • Set the value to #{Octopus.Date.Year}.#{Octopus.Date.Month}.#{CurrentDay}.#{if CurrentDay==Octopus.Version.LastPatch}#{Octopus.Version.NextRevision}#{else}0#{/if}

image
image2311×190 13.8 KB

  • Lastly, bind the NextRevision variable to the release versioning template

image
image3187×1120 231 KB

This should increment the revision correctly, and reset correctly to 0 at the beginning of each day - basically replicate what the i should be doing.

I hope this helps in some way. Please let me know how you go and what you think.

Best regards,

Kenny