We are testing Octopus deployment and we need to perform a few tasks, one of them is to allow to push a package that is already uploaded with the same version. We need it.
Everytime we try to upload it, it always returns (400) Bad Request.
Things we have tried:
Delete the physical folder from Octopus\OctopusServer\Repository
push a dummy package (to refreshing index?)
Push the package we want to upload
– Error (400)
Everything is done by the CMD. We do not wan’t to do it manually over the dashboard.
We are also having this problem. Our build server is set to monitor a branch and automatically build it each time code is checked in. The problem we have is that we don’t want to increment the version number every time we check in code as it is just not practical while we are in development.
This is the command line parameters we are using for MSBUILD…
The package repository is not watched anymore to make it update the indexes. Only pushing the file works or restarting the service.
So the methods that you have tried will not reset that index.
May I ask why you need this functionality. When deploying you cannot roll back if your package is named the same with different files.
We enforce this by design. Would adding an incremental build number on the end be such a bad compromise?
Thanks for getting in touch! While Daniels issue is slightly different, my answer is similar, this is by design that we do not overwrite packages. My suggestion is also to add an incremental build number to the end of your package name.
I also have this problem. Adding an incremental build number as suggested by Vanessa would work but this means that every time the build server runs, it will create a new package with a new version.
If you have an Octopus project consisting of multiple packages, creating a release will deploy all packages, even if they don’t have any new changes.
Does version 3 of Octopus have some kind of new feature to allow this workflow ? Thanks
If you go to Project > Settings tab, there’s an option to have Octopus skip packages that haven’t changed (where the version number hasn’t changed, that is).
Splitting your build process so that it builds the packages separately (and so only runs if that component changes) is probably the best bet.
I am running into the same issue trying to push to the Octopus nuget feed. Our CI server is set to build the branch every 30 minutes. Paul, we can use your suggestion to only build on check-in. However, this will still cause failures in the case someone doesn’t update the AssemblyVersion resulting in a new package name. Another scenario that will cause a build failure due to duplicate package names is if a developer manually kicks a build off.
Ideally, Octopus gives me an option to ignore/skip push failures due to duplicate package names or even the ability to overwrite the package. The only time I will create a new Octopus release is when a developer increments the assembly version.
CruiseControl supports running an executable after a successful build. Therefore, I created a Console Application that is responsible for publishing to Octopus. It checks the build directory for nuget packages and validates each package does not exist in Octopus before uploading. It uses the Octopus API to determine whether or not the package already exists.
It would be nice if this functionality was somehow built-in to OctoPack, but this gets us by in the mean.
Great to hear that you found a solution to get you around this issue.
The underlying reason for this issue is that this API endpoint uses NuGet.exe push to upload the package, and it doesn’t allow overwriting packages. The UI uses the filesystem to upload packages which means we can overwrite the package (by first removing the existing package, and then recreating it from the package being uploaded).
From: Henrik Andersson
<tender2+deb97c2512677a535fe4848259dda7d393010345e@tenderapp.com>
Sent: Friday, August 14, 2015 4:17 AM
To: Воропаев
Виктор
Альбертович
Subject: Re: Overwrite a package [Questions #3372]
�
// Please reply above this line
==================================================
From: Henrik Andersson (Support staff)
Hi Joe,
Great to hear that you found a solution to get you around this
issue.
The underlying reason for this issue is that this API endpoint
uses NuGet.exe push to upload the package, and it
doesn't allow overwriting packages. The UI uses the filesystem to
upload packages which means we can overwrite the package (by first
removing the existing package, and then recreating it from the
package being uploaded).
Thank you,
Henrik
On Thu, Aug 13 at 02:55 PM, Joe wrote:
Came up with a workaround for this problem...
CruiseControl supports running an executable after a successful
build. Therefore, I created a Console Application that is
responsible for publishing to Octopus. It checks the build
directory for nuget packages and validates each package does not
exist in Octopus before uploading. It uses the Octopus API to
determine whether or not the package already exists.
It would be nice if this functionality was somehow built-in to
OctoPack, but this gets us by in the mean.