I have an integration between TeamCity and Octopus. But for some time I’m facing an issue in one of my projects when TeamCity creates a new release it uses package version 0.1.0-996-0001 instead of 0.1.0-1005-0001. Even though I went to Octopus and create a release from there, it also showed me release version 0.1.0-996-0001 as the latest release to deploy.
Below is the attached screenshot of created release log:
Below is the attached screenshot of the TeamCity Create Release step:
If you need more info on this please let me know.
Thanks for reaching out to us today regarding your issue.
When Octopus looks for a version to deploy it will disregard the pre-release semver data.
This means that using
0.1.0-1005 will disregard the
-1005 part of the version.
To get this to work as you expect it to you can change the package version to
0.1.0.1005-0001 and Octopus successfully select the correct package version.
Yes but how it will see other releases i.e. 0.1.0-995-0001,0.1.0-996-0001,0.1.0-997-0001 …etc.
Because on them it was working fine. I start getting this issue when the release version enters into a series of 1000.
I believe we parse the pre-release data as a string, so it will be
1, 1000, 2, 3 ... 9, so 999 will always be greater than 1000. I hope this explains what you’re seeing.
@Justin_Walsh, I didn’t understand your point. Let’s say you parse the pre-release data as a string in that way how 0.1.0-999-0001 is greater than 0.1.0-1000-001.
Also if the case is what you said earlier then what will be the solution for this?
Just jumping in for Justin while he’s offline from the Australia based team.
I’d definitely recommend checking out our docs on Versioning for more info, I’ve paraphrased the relevant parts below:
Versioning schemes | Documentation and Support
Octopus uses a string-based approach to version numbers…
Ordering: Versions will be sorted semantically…
3.0.0-beta.10 > 3.0.0-beta.9
From the Semver docs it indicates that precedence is considered from left to right, so only a single character is evaluated at a time rather than the entire number:
Semantic Versioning 2.0.0 | Semantic Versioning
11.4 Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found…
11.4.2 Identifiers with letters or hyphens are compared lexically in ASCII sort order.
Hope that helps but feel free to reach out with any questions at all!
I have read the documentation but didn’t find anything that would solve my problem.
I’m using GitVersion for the semantic versioning of projects. All other projects are working well with the same configuration but on this one, I’m facing this issue.
Please assist with this.
Thanks for getting back to us.
As Justin was saying as the version has prerelease meta data it is converted to a string.
As prerelease metadata is normally formatted like so:
-beta.1 this string is then sorted alphabetically.
So if you use the version you are using then it would look like the following ( in order of pre-release versioning):
As you can see that the version
-999 is at the bottom of the list e.g. the most latest version.
To get around this you need to replace the hyphen with a dot so that is correctly formatted for Octopus to read the version numerically instead of alphabetically.
Hopefully this clears things up.
Yes, But I’m using GitVersion to automate my versioning process and it generates the version with a dash or hyphen (i.e. -). Is there any way or configuration to tackle this problem on octopus?
Unfortunately, this cant be achieved on Octopus, and will need to done of your build pipelines.
I have looked online at GitVersion and if you are using GitHub actions, then would you be able to send the YAML to our
secure upload site ?
I also found that GitVersion has a number of outputs that could possibly be used to get the correct version
This file has been truncated.
# Execute GitVersion Action (gitversion/execute) Usage Examples
Find out how to use the **gitversion/execute** action using the examples below.
For the GitVersion workflow to execute successfully, you must checkout your Git repository with `fetch-depth: 0` to fetch all history for all tags and branches, as follows:
- name: Checkout
This step is omitted from the examples for brevity.
> The examples use version _0.9.7_ of the GitVersion Execute action. It is recommended to use the latest released version in your own workflows.
Thanks for your reply.
I’m using TeamCity to build pipelines and GitVersion for generating build versions.
If you need anything from TeamCity or something else, please let me know.
Thanks for getting back to me.
Can you send me the part in your TeamCity pipeline that constructs the package version?
This can be either in here or if you like you can upload it using the secure upload link in my last message.
@dom.richardson I have uploaded a screenshot that how I’m supposed to construct the package version. As I told you earlier I’m using GitVersion which generates the version and replaces the default TeamCity build number.
Thanks for sending that over to me.
Could you also send me a screenshot of how the output variable of GitVersion is used to push the package to Octopus.
I have spoken to another collogue and they have recommended that you could use a PowerShell script build step after the GitVersion step.
In this script build step you could get the version that was created by
GitVersion and change the version to match SemVer e.g.
0.1.0.1005 then set it as an output variable.
As this is outside the scope of Octopus, I cant provide any scripts on how to do this.
Actually, GitVersion works under the hood to replace TeamCity’s Build Number with the version generated by itself. I will try to modify it with a PowerShell script and I hope it will work. Thanks for your support, I will give you feedback on it.
I have tried this and now my version is 0.1.0.2058 but it is not correct with my version rule (i.e. ^[^+].*). Please let me know what should be the version rule to entertain versions like this.
Would you be able to send me the full version rule you have in place?
So that I can test this on our test environment.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.