Creating and pushing packages from TeamCity to Octopus

Since version 3.3.1 of the TeamCity Plugin you added a new build runner that can be used to package and push your applications from TeamCity to Octopus.

According to the documentation the Octopus Deploy: Push Packages build runner should be able to both create and push packages. Inside TeamCity, when selecting this build runner, the help text for Package paths says “Newline-separated paths of either package files, or directories to create packages from, that will be pushed”.

However, when I create a build runner and set “Package paths” to point to a folder, it attempts to create a package for every single file in the folder, instead of creating one single nuget of the whole folder. Am I missing something here?

Hi Julian,

Thanks for reaching out. I believe the behavior you are seeing is often a result of the ant wildcards for the folder not being quite right. Would you be able to attach an example of the package path you are specifying? You can redact specific folders names if you need to, the overall structure is the main thing I need to try to troubleshoot what’s happening.


Apologies for the late reply Shannon.

In my TeamCity project I’ve first got three build steps running dotnet publish, with their respective output folders set to %ArtifactDirectory%[project_name]. Finally I’ve got the OctopusDeploy: Create and Push Packages step with the following package paths:


I also tried with variations of this, with / and */ or **/* at the end of each project name, but they all failed. What I did get working was this:

%ArtifactDirectory%/ProjectX/**/* =>
%ArtifactDirectory%/ProjectY/**/* =>
%ArtifactDirectory%/ProjectZ/**/* =>

And really it is not a big issue, since Octopus nicely handles zip-packages as well. But just out of curiosity, I wonder what would be the correct configuration for the package step to produce nupkg-files.

Hi Julian,

What you got working is what I was expecting to see.

I’ve spent some time digging through the code to help explain what was happening. I think what it comes down to is that it relies on some functionality built in to TeamCity. That functionality expects the %ArtifactDirectory%/ProjectX/**/* => syntax, and the file extension is what governs the ArtifactsPreprocessor is uses (the thing that does the file handling). When it has the .zip it gets the preprocessor you want, if it can’t determine the preprocessor you get the per file behavior you were seeing.


Thank you for the clarification, Shannon.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.