I’m seeing an issue with octopack when generating revision numbers. What seems to be happening is this:
I kick off a build and it’s numbered 1.0.11.12345 for example. This appears as a release as I’ve set Octopus to automatically create one for each package.
I kick off a newer build, which for some reason is numbered 1.0.11.12344. This does not create a release as Octopus see’s the number as less than the greatest package number.
Is it normal for octopack to create a lower package number at a later date? Is this something I need to be controlling?
I’ve attached a document with some images in it, in case it helps.
Any ideas?
I think the packages should really be a) sequential in some way or b) based on creation date for ordering rather than version number.
Thanks for getting in touch! When you use OctoPack, the NuGet package version number will come from (in order of priority):
The command line, if you pass /p:OctoPackPackageVersion=<version> as an MSBuild parameter when building your project
The [assembly: AssemblyVersion] attribute in your AssemblyInfo.cs file
Those would be the first places to look to know from where is Octopack getting the version number. If you could share us the current values of those 2 configs it’ll help us getting to the bottom of the issue. Screenshots would rock.
At the moment we’re not providing the MSBuild argument explicitly, so the version should be coming from the Assembly version, we have the following setup:
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '’ as shown below:
[assembly: AssemblyVersion("1.0.11.")]
[assembly: AssemblyFileVersion(“1.0.11.*”)]
It seems the revision numbers are non sequential.
Would that suggest we’d be better using say the build number to ensure the packages are created in order to trigger the auto releases?
The format of the version string is: major. minor. build. revision.
If you put a * on the place of the revision (and hardcode the rest), its value will be equal to the number of seconds since midnight local time, divided by 2. Hence this value alone cannot be trusted to systematically increment the assemblyversion on each build. (It’ll fail if the build 1.0.0.* runs one day at 2:01pm and the other day at 2:00PM)
If you put a * on the Build (and hardcode the rest), its value will be equal to the number of days since January 1, 2000 local time. This value alone cannot be trusted to systematically increment the assemblyversion on each build (It’ll create the same number if 2 builds run on the same day)
Now, if you set both values with a *, you’ll be guaranteed to always have an incremented AssemblyVersion (hence a Nuget package version), as no 2 builds will run the same day, at the exact same second.
TL;DR : go with [assembly: AssemblyVersion("x.x.*.*")]
Sorry for re-opening this call, I was wondering if you could help me with a related version issue.
When I originally build the project and published it to the nuget feed, it had a hard coded version number of 1.0.0.0. This caused some problems as I had a ‘bad request’ issue when ocotopack was trying to publish to the nuget feed (presumably because that package version already existed).
Oddly, I seem to keep getting the 1.0.0.0 version back every now and again (like every 10th build for example (not an exact number)) which then causes all my builds to fail with a bad request until I go and delete the 1.0.0.0 package from library > packages.
Do you have any ideas where the rogue 1.0.0.0 package is coming from?
If it’s any help, I seem sometimes to get two version pushed from octopack within 2 minutes of each other when I’ve only triggered one build. I think maybe something is cached / broken in my octopack setup as this doesn’t happen on other projects.
Any thoughts on how to clean up the octopack settings, or anywhere in octo server I could look?
No worries for re-opening the ticket! Are you building more than 1 project in that solution? If that is the case, have you modified the AssemblyInfo.cs file on all the projects that you wanted to pack?
What is inside this rogue package? The same content as in the correct package?
In this solution there are several projects but only one is set to use octopack (it’s a website with a few supporting class libraries).
I’m afraid I’ve deleted the rogue package (this time) but will kick off a few builds and have a look inside when it comes back. In terms of what’s output into the ‘pairs’ of packages where are produced they seem to have the same number of items, but slightly different size on disk. Doing a quick visual comparison of the folders, even the KB sizes of each files seem to the same, so they must be multiple tiny size changes which add a few bytes to each file, when rounded they seem to total a few hundred KB.
