CODEWITHSUNDEEP
teamcitynuget-packagenuget-server
Kerry
Kerry

Reputation: 41

Team City NuGet Server not publishing all package versions

We are using Team City 9.1.5. Our main application is very old and complex, and over the years we have had to write several utilities to support customers. The utilities need to reference application components, and multiple versions of the utilities are maintained to correspond to different application versions.

To avoid creating a new release of the application every time a utility needs to be updated, we are using the Team City NuGet feed to host versions of our application's dlls. These are then referenced by the utilities in Visual Studio, etc.

The original solution was to create a separate build configuration for NuGet packages for every released version of the application. These are manually triggered to reduce the number of packages for a specific version of the app (i.e. I don't need a package for every build, just stable).

Over time, the number of supported versions of the application has grown, and so has the number of NuGet package build configurations. I am trying to consolidate these separate build configurations into a single build configuration with multiple build steps - one step per version. But when run, Team City will only publish the latest version of a package from a single configuration. Examination of the configuration's artifacts show that all all of the different versions are built and retained, but only the latest is published.

When I break the exact same build steps out into multiple configurations, one build step/configuration per version, the artifacts all show up again.

Is there a way to get Team City to publish all of the artifacts from a single configuration, even if there are multiple versions of the same package?

Upvotes: 1

Views: 562

Answers (1)

Kerry
Kerry

Reputation: 41

Per JetBrains, "Unfortunately it's a known bug in TeamCity: https://youtrack.jetbrains.com/issue/TW-40363, please vote for it."

My solution for now is to go ahead with the separate build configurations, although that will add maintenance overhead and "noise" to the TeamCity projects page.

We are also discussing an alternative solution of using one build configuration and pushing to a separate nuget package feed other than Team City's.

Neither of these options is desirable as both will require additional resources to implement.

Upvotes: 1

Related Questions