Nuget Dependency Trigger Package Version Spec questions.

I was wondering if I could get some details on the function of the Package Version Spec portion of the Nuget Dependency Trigger.

We currently have a situation where we have two builds producing different versions of a package with the same Package Id. Both of these builds should trigger dependent builds that will deploy the different versions of the package to different environments through Octopus.

Basic view of the Builds and versions.
Package Id: Lightning
Version: 2.5
Build1
DependentBuild1

Package Id: Lightning
Version: 3.0
Build2
DependentBuild2

If we do not specify a Package Version Spec we could end up with Build1 triggering both DependentBuild1 and DependentBuild2 and the same with Build2

An example of the full versions produced for each build would be Build1 producing a version similar to 2.5.220 and Build2 producing a version similar to 3.0.18. Basically a major.minor.build format with the build number increasing with each build.

When we initially configured the Package Version Spec for the dependent builds we enetered in 2.5 for DependentBuild1 and 3.0 for DependentBuild2. These builds have since never triggered off Build1/Build2 and have to be kicked off manually.

When digging around google for more details on how exactly the Package Version Spec field actually functions I didn't find any examples where people were actually filling in this field and only found the folowing information in the documentation on the Confluence site.

"Optionally, you can specify package version range to check for. If not specified, TeamCity will check for latest version."

What is the corret way to specify a package version range? I have also tried 2.5* and 3.0*, but I don't know if this is the correct way to go about formatting the input for the Package Version Spec field. I tried a few builds with it setup that way and the Dependent builds did not trigger so I assume it's incorrect. I want to ensure that each build of Build1 kicks DeploymentBuild1 with the latest Lightning2.5 and the same for Build2 and DeploymentBuild2. I'd rather not have to change the Package Id to also include the version if I can avoid it.

1 comment
Comment actions Permalink

Seems like this is an old topic, but have you managed to find a workaround? We are encountering the same issues with tC package ver spec

0

Please sign in to leave a comment.