I’m using OctoPack 1.0.107 and its new ability to push the built .nupkg packages to a nuget server. I’m building the projects in the solution using an MSBuild script.
I have the AssemblyVersion of my project (a Windows service) set to 1.1.* so that each build gets a new unique Assembly version. OctoPack is then reading the AssemblyVersion and creating a new .nupkg with the version embedded and also in the filename. All good. But the default behaviour of the OctoPack build is to place the nupkg files in the bin\Release folder. After two builds I therefore end up with my ServiceProject\bin\Release folder filling up with files like:
Service.1.1.4589.29250.nupkg
Service.1.1.4589.29626.nupkg
When OctoPack tries the push, it tries to send all the packages in the folder eg:
Attempting to build package from 'Service.nuspec'. Successfully created package 'bin\Release\myproject-Service.1.1.4589.29626.nupkg'. Copy packages: bin\Release\myproject-Service.1.1.4589.29250.nupkg;bin\Release\myproject-Service.1.1.4589.29626.nupkg to bin\Release\ OctopusPublishPackage: "C:\git\myproject\Service\..\packages\OctoPack.1.0.107\tools\NuGet.exe" push "bin\Release\myproject-Service.1.1.4589.29250.nupkg;bin\Release\myproject-Service.1.1.4589.29626.nupkg" ABCD1234 -s http://nuget.example.com Could not find a part of the path 'C:\git\myproject\Service\bin\Release\myproject-Service.1.1.4589.29250.nupkg;bin\Release\'.
So I guess there are two parts to my question:
- How do I stop the nupkg files building up and therefore constantly being shuffled around by the ‘Copy packages:’ stage? I assume I’ll need to build a target to delete them into my build script. It would be nice if the default behaviour meant I didn’t need to add a workaround.
- If I don’t fix 1) can I tell OctoPack to push only the package it just built?
Cheers,
Paul