Team city create the nupkg package which is pushed to octopus and can be seen in the Library>packages. It seems then that octopus is internally recreating these packages and changing the package name.
For example TC may pack up and send over a package called “1.10.0-beta-28919” this then shows correctly in the projects overview page for example:
It seems that then Octopus for some reason recreates this package and rename it and creates duplicates?!, e.g:
Package names in the project overview are then also changed too:
I’m not sure whats going on here as it seems bizarre, all I can think of is Octopus isn’t liking the “beta” text in the package name.
Octopus shouldn’t have any problem with pre-release tags (e.g. 1.0-beta), and it shouldn’t be able to overwrite existing releases.
It is worth noting that there is a difference between a Release and a Package. A Release doesn’t necessarily have to have the same version number as a package used within that release. So, it could be that the package is always being uploaded with the version number 1.10.028922, and it is just the release number that is being changed.
I’m assuming that the two screenshots are from the same project? Does that project have any channels configured outside the default ones?
Also, if you navigate to the Releases page for that project, can you locate the 1.10.0-beta-28865 release at all?
Here are a couple of additional items to check:
What commands is TC running when performing the package push and the release creation? You should be able to find these in the build logs. The commands will begin with octo push and octo create-release
Does the project have automatic release creation enabled? If you select the project and navigate to the Triggers page in the menu on the left. Then check the far right of this page, is there anything configured?
e.g.
Currently it only has 1 channel, which is its default one connected to a named lifecycle where it just tweaks the retention policy (basically only keeps 3 days worth), and a couple of phases based on release process i.e. Internal > Azure UAT etc
I can see the beta release there along with additional releases which Octopus seems to have created automatically/not part of TC:
With automatic release creation enabled on the project, anytime a new version of this package is pushed to Octopus, it will automatically create a new Release with the version number of the new package.
In your project here, it looks like the 1.10.0-beta-28919 package was pushed to Octopus at 11:43, which will have triggered the creation of the corresponding release.
Then, 10 minutes later and onwards, the other packages were pushed, resulting in those Releases being created and the beta release no longer being displayed on the project overview due to too many “newer” releases to display.
I’m assuming that these newer packages (1.10.028920 - 1.10.028925) are being created and pushed by the same TC pipeline that created the beta package.
If not, it may be that you have another build pipeline that is creating and pushing these packages.
The only thing pushing to Octopus is TC and the TC builds are triggered by PR into the main branch, and as I PR review all merges in I can confirm there hasn’t been any additional work to trigger anything from TC.
Though… I’ve just noticed a configuration change in TC thats been made so TC builds from all branches, and yes, these align up whats in Octopus.
Seems like there is no error and its an oversight on my part, apologies for the time taken
In the library > packages I can see the correctly built packages done by TC, but these aren’t being picked up by the releases on the project.
Theres been a number of builds (all with beta/alpha in the names) and these haven’t been pulled through, if I manually create a release it will show the latest beta package, but obviously I want this picked up automatically
If so, Octopus won’t be able to determine that those are new packages as it will only look at the version number part before the first -.
So, when I uploaded those packages with automatic release creation enabled, only the first one created a release because it saw the following two as the same package version.
There are two main ways to fix this:
Add the Create Release step to your build pipeline and disable Automatic Release Creation. This will create the release whenever the pipeline runs instead of relying on Octopus to detect the new package.
Amend your package versioning to include the number at the end as part of the version number. e.g. 1.10.00.28921-alpha. Then as long as the larger number increments with each build, Octopus can detect the package as new.
e.g.
If you moved the tag to the front, I think Octopus would see it as part of the package name rather than the version.
e.g.
Uploading TestPackage.alpha-1.10.00.28921.nupkg results in: TestPackage.alpha-1 - Version: 10.00.28921
Thanks Paul, moving it to the end so that versioning is major.minor.patch.buildnumber-alpha|beta seems to have the effect we were looking for, as you said it was down to do with the numbers order.
Is there a way to make sure specific versions are only acceptable on specific envrioments. For example an alpha release is only allowed on one enviorment and likewise a beta release on another?
To limit package versions to specific environments, you’ll want to look at Channels and the version rules that can be set within them.
The basic idea would be that you’d have the main release channel with whichever environments you want your main releases to go to (e.g. 1.10.00.28921), and then you’d have an Alpha channel limited to your test environments.
Then you’d set a version rule on each channel to limit the package versions used for releases in that channel.
e.g.
My Main channel with ^$ pre-release tag (prevents any packages with a pre-release tag)
One downside to using Channels is that the Automatic Release Creation feature can only target a single channel.
So, you can leave it enabled to create releases for your main channel and be certain it won’t use pre-releases packages.
However, you’d have to manually create releases for the Alpha channel.
The alternative would be to disable the automatic release creation trigger and add the Create Release step to your build pipeline. When you create a release that way it would automatically select the channel that matches the package, so, would use both main and alpha channels depending on what package was used.
