Semantic versioning not working on build 0

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

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

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

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

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

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

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

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)?

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

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}

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

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

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