Basically, I was trying to reset a piece of the version number after the month changes, so that it doesn’t do something like moving from 2018.08.05 to 2018.09.06. What I noticed was that Octopus.Date.* creates leading zeros, whereas the Octopus.Version.Last* numbers do not. So I am trying to do a comparison like
but it ends up as a comparison of 8 == 08, which ends up false. If I just use {Octopus.Version.Channel.NextPatch} directly, it increments correctly, but that obviously wouldn’t reset after the month changes.
So, I guess my question is, is there a different way I should be doing that comparison, or is it just a general issue with comparing those two variables?
If it helps, the specific clause is #{Octopus.Date.Year}.#{Octopus.Date.Month}. #{if Octopus.Version.Channel.LastMinor == Octopus.Date.Month} #{Octopus.Version.Channel.NextPatch} #{else}1 #{/if}
Thanks for getting in touch. The issue you link to is about the pre-release section which is intended to support more free form data. You’re experiencing the issue on the primary parts of the version (major minor, patch).
The SemVer spec states leading zeroes are not allowed, our first suggestion is you change the approach of your versioning.
If that’s not suitable we have some other workarounds that involve some extra deployment steps. If you have a script step earlier in the process, it can use C# or PowerShell to set an output variable that will be your version or the date in a suitable format to compare.
Then your existing step can use that variable value to do it’s conditional logic.
We’ve raised an issue to make Octopus.Date more capable to support other formats as you would be able to using C# to define a format, but it’s going in our feature backlog at the moment.
Thanks for getting back to me! I’m aware that SemVer doesn’t like leading zeros, and either way, I’d prefer not to use them. The fact that the Octopus.Date.(Month|Day) variables use them is really the only reason I was running into this. If those variables, others, or some additional function existed to get segments of the date without them, I think my issue would be solved, so thanks for raising the issue!
Thanks also for the reminder about output variables. If at all possible, I’d prefer to just have the regular version template handle it, but I think an additional script step may also work in the meantime, Does a script step have access to the (Last|Next)Patch variables, or is that only in the context of release versions? Thanks!
A Script step in the same deployment process will have access to all the same variables as the other steps, it just may not have access to anything very specific in some other step, but again Output variables is there if you need to build more interconnection of variables.
For the current problem, this new script step will just be doing some basic checks and setting more variables. Have a go, even if you make a quick test project that doesn’t actually have an impact on an environment (sort of dry run project).