Hi Octo Team,
We have couple of external feeds configured in our octo server and we are using them in our projects. The external feeds refer to an artifactory instance.
Recently I published a pre-release version of a package frontier-nginx-conf.0.1.16-Use-Absolute-Path.1.nupkg, consumed it in a release then deployed to server. Then. I published an increment frontier-nginx-conf.0.1.16-Use-Absolute-Path.2.nupkg.
Now, the second is not visible to Octo and it still shows the first nuget (In creating release or testing external feed). The feed is available in artifactory feed much like the first one was.
I tried following workarounds -
- Restarted octo Deploy service.
- Removed first nuget from artifactory.
- Removed downloaded nuget artifact in octo server.
Still it showed same version in like (attached)
No such problem exists when using non-release versions/numeric versions like 1.0.5 etc. They are available w/o above mentioned hassles.
So, does Octo have issues identifying SemVer based nugets or are they cached somewhere?
Thanks for getting in touch!
I don’t believe there should be any caching taking place here.
I’ve run a quick test on my local instance and an artifactory nuget feed and I do see the correct package selected.
When you’re creating the new package is the nuspec file being updated to reflect the version change? I’m wondering if that remains the same then it could explain why Octopus keeps picking the old package.
Hi @paul.calvert ,
Thanks for the reply.
Yes, the nuspec file is updated.
Extract from nuspec file inside package -
<?xml version="1.0" encoding="UTF-8"?>
When querying an external feed what is the structure of the query that is sent. Maybe I can hit that to see where the blockage is - on the artifactory side or octo side?
I believe the API call being made is:
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.