Problems with finding a package with multiple feeds while creating and running a release

stenbrinke · 11 June 2019 14:46

Hello!

I have an issue with Octopus deploy, multiple external feeds and creating a release from Azure DevOps because Octopus Deploy wont pick the correct package from the 2nd external feed; it only sees the one feed.

The situation is as follows:

Package feed 1: (This one has been used for a while and is used for multiple projects)

Package 1 (v0.0.35)

Package 2 (v0.0.03)

Package 3 (v1.3.03)

Package 4 (v1.0.02)

Etc…

Package feed 2: (New)

Package 1 (v1.0.5)

Package 2 (v1.0.5)

I am currently working on updating our build pipeline and we are migrating from TeamCity to Azure DevOps but for now we would like to keep using Octopus Deploy for releases.

During a build, TeamCity creates a couple packages and publishes them to its Nuget Feed (which is configured as Package feed 1 in Octopus Deploy) and then creates a release in Octopus Deploy. Currently, Octopus Deploy then uses that feed to retrieve the package and release it.

Because I am now using Azure DevOps as our build environment, I have set it up in the same way; we now have a new Package feed ( Package Feed 2 ) which only contains package 1 and 2 with the same name and metadata, except the version number is higher. I want this feed to be used because the package has a higher feed or … well, because I want to!

This new feed is added as an External feed in Octopus Deploy and Make use of the extended API is disabled in the external feed settings. When I test this feed, it can find my newer package versions.

When I build our application is Azure DevOps and publish package 1 and 2 to Package Feed 2 , everything goes well in Azure DevOps and a release is created.

The octo.exe command looks like this:

Octo.exe create-release --project="PROJECT" --releaseNumber="" --channel="Default" --server=SERVER --apiKey=*** --enableServiceMessages --releaseNotesFile=RELEASENOTES.MD --defaultpackageversion=PACKAGE-VERSION

Sadly, Octopus Deploy can’t execute the release because it says the following.

The package **Package1** .1.0.5 could not be downloaded to the package cache from NuGet feed ' **Package feed 1** ' at https://teamcity.agile.works/httpAuth/app/nuget/v1/FeedService.svc/ after making 5 attempts over a total of 101s. Make sure the package is pushed to the feed and try the deployment again. For a detailed troubleshooting guide go to http://g.octopushq.com/TroubleshootMissingPackages System.Exception: Unable to download package SevenStars.1.0.5 from NuGet feed 'teamcity' at https://teamcity.agile.works/httpAuth/app/nuget/v1/FeedService.svc/: The download package result was: NotFound ---> System.Exception: The download package result was: NotFound at Octopus.Core.Packages.NuGet.ExternalHttpNuGetPackageFeed.DownloadPackageToLocalCache(String packageId, String version, ITaskContext taskContext, LogContext logContext) --- End of inner exception stack trace --- at Octopus.Core.Packages.NuGet.ExternalHttpNuGetPackageFeed.DownloadPackageToLocalCache(String packageId, String version, ITaskContext taskContext, LogContext logContext) at Octopus.Core.Packages.DeploymentPackageDownloader.<>c__DisplayClass11_0.<DownloadPackage>b__0()

June 11th 2019 16:19:38

Error

The package Package2.1.0.5 could not be downloaded to the package cache from NuGet feed ' Package feed 1 at https://teamcity.agile.works/httpAuth/app/nuget/v1/FeedService.svc/ after making 5 attempts over a total of 100s. Make sure the package is pushed to the feed and try the deployment again. For a detailed troubleshooting guide go to http://g.octopushq.com/TroubleshootMissingPackages System.Exception: Unable to download package SevenStars.Website.ResourceGroup.1.0.5 from NuGet feed 'teamcity' at https://teamcity.agile.works/httpAuth/app/nuget/v1/FeedService.svc/: The download package result was: NotFound ---> System.Exception: The download package result was: NotFound at Octopus.Core.Packages.NuGet.ExternalHttpNuGetPackageFeed.DownloadPackageToLocalCache(String packageId, String version, ITaskContext taskContext, LogContext logContext) --- End of inner exception stack trace --- at Octopus.Core.Packages.NuGet.ExternalHttpNuGetPackageFeed.DownloadPackageToLocalCache(String packageId, String version, ITaskContext taskContext, LogContext logContext) at Octopus.Core.Packages.DeploymentPackageDownloader.<>c__DisplayClass11_0.<DownloadPackage>b__0()

As you can see, it is using Package feed 1 and does not even try to use Package feed 2.

I would like that it searches BOTH feeds for the most recent version; I’d prefer to not have to use the –defaultpackageversion parameter at all.
Or I would like a way to be able to say what feed should be used. Or the default should just be feed 2 by now and then go back to feed 1.

Some of our current release definitions in Octopus Deploy still use Package Feed 1 and I do not want those to break!

I hope you can help me with this issue!

Greetings,

Sander ten Brinke

robpearson · 12 June 2019 05:56

Hi Sander,

Thanks for the question. I understand your scenario, but unfortunately, this is not possible as this is not how feeds were designed. i.e. Octopus does not search multiple feeds for specific package versions.

I don’t think there is a good solution for your scenario. A hard cut-over would be the best option, but this is challenging since you are migrating. The only option I can think of is to push older copies of your packages to your Azure DevOps Artifacts repo and then recreate releases in Octopus (assuming the deployment process, variables etc. haven’t changed). Obviously, this isn’t an ideal option and may not work.

Hope this helps.

Thanks

Rob

stenbrinke · 12 June 2019 06:47

Thanks for the answer, @robpearson

That’s sad news to hear.

Can you tell me what the purpose of having multiple external feeds is, then? Because apparently only one can be used; what are my benefits of having a 2nd feed?

Is it not possible to tell my release project to use the other feed (in the web portal or something)?

robpearson · 13 June 2019 06:24

Hi Sander,

Thanks for the reply. The are a quite a few benefits of multiple feeds. Primarily, it’s flexibility so teams with different requirements so they can have different feeds. We support NuGet Feeds, Maven, Docker and more.

There is essentially a 1:1 relationship between packages and feeds. We assume packages will be in a single feed and there isn’t a way to dynamically search different feeds based on their version. I’m sorry I don’t have a better answer.

Hope this helps.

Thanks

Rob

stenbrinke · 13 June 2019 07:20

Hey Rob, I hope you can still answer my question today!

Thank you for this explanation but you still haven’t answered my previous question:

Is it not possible to tell my release project to use the other feed (in the web portal or something)?

When a release is created in octopus, it pulls the package that has to be released from the external feed. Right now it searches in Package Feed 1 but it should search in Package Feed 2 because this is the one that is used for migrating.

You say:

We assume packages will be in a single feed

I want my release definition to use Package Feed 2, and NEVER package feed 1. There is No need to dynamically search different feeds; the newest packages will be in Feed 2.

How can I do that? How do I tell my release definition to use a different feed?

So:

External Feeds
Feed 1
Feed 2

Release definitions
Release definition 1: Use Feed 1
Release definition 2: Use Feed 2

How do I do this?

robpearson · 14 June 2019 01:09

Hi Sander,

Sorry about that. I’ll try to answer your questions clearly now.

Is it not possible to tell my release project to use the other feed (in the web portal or something)?

Unfortunately, it is not possible to update the feed/packages used in an existing release. All dependencies are snapshotted when a release is created and this is fixed/locked. This is a big part of what makes Octopus deployments repeatable and reliable in that the underlying process cannot change.

That said, there are a couple other options.

Update your projects to use the new feed and recreate the releases pointing at the correct versions. NOTE: I’m assuming you’ll push the required older packages to the new feed.
Update your projects to bind the Feed ID to a project variable. Variables are snapshotted at release time as well but they can be updated later via the Release Details page (i.e. selecting a release from Project → Releases in the Octopus web portal). In this scenario, this could enable you to change the feed used for existing releases. That said, this has to be set up beforehand so it might not work for you right now. It also updates ALL variables which may have unintended consequences. The variable will need to contain Feed IDs and they can be found by looking at the full list from the Octopus API: https://myserver-url/api/feeds. Examples include feeds-builtin and Feeds-1, Feeds-21 etc. Our docs talk about how to bind Feed IDs though it talks about binding them to environments which isn’t relevant for you.

So there isn’t an ideal solution for this but there are a couple options.

Hope this helps.

Thanks

Rob

system · 14 July 2019 01:11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.