We generate a ton a build packages on TeamCity and only end up deploying a small percentage of these packages to Octopus. This is ok for normal work flow, but we occasionally have a need to redeploy a package. We generate many builds, it is not uncommon for that build package to be cleaned up by the time we get around to doing the redeploy. Since TeamCity is not part of the deployment process it will never know what build packages need to be kept. However, Octopus does!
Is it possible to configure Octopus to copy deployed NuGet packages to its internal NuGet server during a deployment? Do this would allow us to have different retention policies for builds which have been deployed vs builds which have not.
Hi Brian,
Thanks for the question. Would a solution like this work?
Octopus has a built-in NuGet repository that you can push to. Instead of having Octopus read packages from TeamCity, have TeamCity push them to the built-in Octopus repository.
In the next version of Octopus, we’ll be adding retention policies to NuGet packages, and will smartly tie them to releases - if there’s a release in Octopus the NuGet packages will be retained. When the release is deleted (e.g., you only keep the last 10 releases deployed to Dev) then the packages will be cleaned up.
Paul
Hi Paul,
I actually just put together a powershell script which we will run during a deployment. It downloads the target NuGet package and pushes it to the Octopus NuGet server. It would be neat if this functionality was baked into Octopus to reduce our need to maintain scripts, but we can do without.
If the retention policy keeps the NuGet package around as long as there is an active release for it, this will work perfectly for my needs. We look forward to seeing the next version of Octopus!
Regards,
Paul Stovell
Octopus Deploy
W: octopusdeploy.com | T: @octopusdeploy http://twitter.com/octopusdeploy
After upgrading to Octopus 2.4.5.46 my script has been returning an error when trying to push a nuget package which already exists:
@@@
System.InvalidOperationException: Failed to process request. ‘Bad Request’.
The remote server returned an error: (400) Bad Request… —> System.Net.WebException: The remote server returned an error: (400) Bad Request.
at System.Net.HttpWebRequest.GetResponse()
at NuGet.RequestHelper.GetResponse(Func1 createRequest, Action
1 prepareRequest, IProxyCache proxyCache, ICredentialCache credentialCache, ICredentialProvider credentialProvider)
at NuGet.HttpClient.GetResponse()
at NuGet.PackageServer.EnsureSuccessfulResponse(HttpClient client, Nullable1 expectedStatusCode) --- End of inner exception stack trace --- at NuGet.PackageServer.EnsureSuccessfulResponse(HttpClient client, Nullable
1 expectedStatusCode)
at NuGet.PackageServer.PushPackageToServer(String apiKey, Func`1 packageStreamFactory, Int64 packageSize, Int32 timeout)
at NuGet.PackageServer.PushPackage(String apiKey, IPackage package, Int64 packageSize, Int32 timeout)
at NuGet.Commands.PushCommand.PushPackageCore(String source, String apiKey, PackageServer packageServer, String packageToPush, TimeSpan timeout)
at NuGet.Commands.PushCommand.PushPackage(String packagePath, String source, String apiKey, TimeSpan timeout)
at NuGet.Commands.PushCommand.ExecuteCommand()
at NuGet.Commands.Command.Execute()
at NuGet.Program.Main(String[] args)
@@@
Is there a way to check if a package exists for a deployment from a deployment step powershell script?
Hi Brian,
Thanks for the information and sorry about this. You can check if a package exists using the Octopus REST API - an example is:
https://demo.octopusdeploy.com/api/packages/packages-OctoFX.Database-2.7.2702
Where the URL is /api/packages/packages-{id}-{version}
More information on using the API is available here:
Hope this helps,
Paul
The same happens to us in this scenario:
Teamcity is running on port 8333, and routed behind ARR via https://
In octopus, we have configured the nuget feed via https and the tests are working.
However when the tentacle is trying to download it fails with 400 HTTP error as above.
Not sure what we can do.
Hi,
If you add the TeamCity NuGet feed as a package source in Visual Studio, and try to search and install packages from it via VS, does it work? This will help us to figure out if the issue is NuGet/TC or Octopus.
Paul
That is on a production server. We don’t have Visual Studio in there.
I think the issues is clearly octopus, since when you search the packages through Library -> Nuget Feed it works.
I’ve noticed this happens (400 Bad Request) when you push a package and that version already exists on the internal server…
Hi,
Sorry for the delay in getting back to you here. If the Octopus Server is able to access the feed and packages correctly in this instance we would suggest choosing:
“Octopus Server will download the package, then securely download it to the tentacle”.
Please let me know if this resolves the issue.
Vanessa
It works that way, but is painfully slow, about 10seconds slower than just downloading from tentacles.
We ended up to set up the SSL certificate in Tomcat and accessing the feed on the teamcity port over https