Running into a strange issue on a new Octopus server (problem doesn’t exist on our main one).
Although the external feed, when tested, shows the correct most recent package(s), when I attempt to create a release, the “latest” package for this particular feed are MUCH older than what it should report. (Note that these packages DO exist, as we keep many old packages on our repository)
Any ideas what I’m doing wrong here?
Hi Peter,
Thanks for getting in touch! Can you confirm that the package step is using the same feed that you are testing? Sometimes this is the forgotten step to be updated. (Don’t forget to test on a new release as the process is part of the snapshot.)
We never cache results - so if you are using the correct feed on the step, the next thing to check would be if you are using pre-release tags, channels or anything that could determine an unexpected result for latest.
Screenshots of the packages and your release creation screen showing results will help me determine what the issue might be.
Vanessa
Attaching screenshots.
As far as I know, we use no pre-release tags and everything is on the same channel.
For what it’s worth, I used the octo.exe command line to to export the project from the working Octopus server and imported it into the new Octopus server. However, the environments, machines and many other things are different, so I manually edited the JSON results to match the destination Octopus, as much as I could.
Also, I don’t know if it matters, but our main Octopus is a licensed version, but the new Octopus is the free Community Edition.
Hi Peter,
License does not effect this manner of behaviour. In fact each paid license allows for 3 Octopus instances so you could use your existing license in this new instance if you are only using it once currently.
As for the error - everything you sent looks fine but there are a few more things we might need to check. Could you answer or provide:
- Octopus server version you are using?
- Screenshot of the create release page where the package numbers are shown
- Screenshot of the packages themselves in your NuGet feed (not from our test page search)
- Confirmation that all package versions are the same across Octopus, and your feed (NuGet likes to eat trailing 0’s and we would like to be able to exclude that from the causes).
- Which NuGet feed vendor are you using?
You could also confirm (via DB query) if the feed details are the same from your original server and this new one for the feed in the feeds table. That should hopefully rule out the import as a cause.
Vanessa
Changed back to public, so my colleagues can view this.
Just for fun, I tried deploying the release and it found the packages just fine.
Strange.
Will work on getting answers for your questions once I finish getting this all to work.
- New is 3.8.5 - Main is 3.8.9
- Attached
- Attached, but I can only show a snapshot of a handful at a time, as we have a LOT of versions of each. (over 100)
- Not sure what you mean here. Both octopuses have the same feed/repository. We don’t have a separate repository for the new Octopus.
- Artifactory
No idea how to do a DB query to determine what you need. If you can provide the exact query, I will forward to our DBA.
Hi Peter,
Thanks for your answers. For 4. NuGet started removing trailing zeros from version numbers, but your screenshots have cleared that up. We have tested a few things and it’s looking like an Artifatory issue with our implementation. Could you answer the following two questions:
Can you confirm the version of Artifactory that you are using, and if you are using the virtual repository feature (where you setup 2 NuGet feeds and combine them into one).
Vanessa
I have found the same issue.
Whilst the project worked perfect previously utilizing Nuget (and saving the nupkg in MyProject\bin\MyProject.Servername.{versionnumber}.nupkg), it now by what seems to be on its own accord, started utilising Zip
There now is no .nupkgs file anymore, it is however creating a zip in the MyProject\obj\Debug\Package folder. e.g. MyProject.zip (no version number)
This seems to be a full webdeploy now, and in the package folder it includes files and folders :
[PackageTmp]
MyProject.deploy.cmd
MyProject.deploy-readme.txt
MyProject.SetParameters.xml
MyProject.SourceManifest.xml
MyProject.zip
I need my versioned nuget package please - How do I get it back? Is there a switch I need to state not to use webdeploy?
Had this issue previously.
This was my problem:
The reference to Octopack was broken in the project
I was thrown off by the fact that the last step that I saw, was Web Deploy.
What I did not know was that this is a normal part of the Octo process and that immediately after the Web Deploy section is run, then Octo runs.
Thus reinstalling OctoPack via NuGet solved the issue.
Artifactory version 4.16.0
We are NOT using a virtual repository (had major problems with them in the past).
Hi Peter,
I’m going to take over this one from Vanessa since I’ve been working with our external Nuget feed support quite a bit lately. We’ve had a few issues with Artifactory, but thus far they have been with older versions of Artifactory than you are running and with virtual repos.
Since you aren’t seeing this issue on your Octopus 3.8.9 server you may which to try upgrading your 3.8.5 server before you go too much further. We made a few Nuget fixes in between those versions, although I can’t see one that would have changed this.
The reason you see different versions available in the feed Test and the release page is we use slightly different Nuget APIs on those two pages, and unfortunately sometimes they behave a little differently. The best way to get to the bottom of this is to take a trace of the network calls we’re making to Artifactory and the responses, with Fiddler (http://www.telerik.com/fiddler) if you are familiar with that, and send the trace to us.
The guys over at MyGet have a guide on capturing a trace with fiddler here: http://docs.myget.org/docs/reference/capturing-traffic-with-fiddler You can ignore all the proxy stuff in their “Tips for capturing NuGet and VSIX traffic” section, and instead run the Octopus Manager application, click “Change proxy server settings” and set as per the attached image, our Nuget API calls will go through the configured Octopus proxy, which will be Fiddler in this case. If you need any more guidance just let me know.
Regards,
Mark
I can try doing a fiddler capture.
I don’t think the version of Octopus is the issue, as we have no issues with the other feed on the same machine. (notice in one of the screenshots, it had no trouble finding the correct versions of the Bootstrapper and Nxlog packages, which are on a different repository feed, from the same Artifactory.
Sent from my Samsung Galaxy smartphone.