Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Two tier nuget Feeds and controlling build server access with minimum changes to yaml build/pipelines
-
Hi,
I've setup a two tier Nuget feed where feed "A" has a connector setup to Nuget.org and feed "B" is where I promote packages from feed "A". Developers have access to both A and B but the build server only has access to"B". The developers use a Nuget.config in their solution to control where nuget packages come from. The file is part of source control and is used by both the developers and the build server. The problem I have is that the Nuget restore task on the build server fails because it can't access feed "A". To fix this I either need the Nuget restore task to ignore errors which means it will also ignore not finding package errors, so this is not optimum. The other option is to have a different Nuget.config for the build server and another one for the develops. Also not the best solution. This is using AzureDevOps on prem yaml pipelines. Is there a way for this to work or maybe a different setup is needed. Any input would be appreciated.Thank you,
Paul
-
Hi @pbinnell_2355 ,
It sounds like you've built a kind of package approval process?
https://blog.inedo.com/nuget/package-approval-workflow/
If that's the case, you'll need to promote the packages developers need to feed "B" or ask the developers to not use unapproved packages.
Thanks,
Steve
-
Yes, that is what I have setup but the problem is that it seems I will have to have two different build processes. One for the developers on their machines and one for the build server. I am trying to do this without having this situation and am trying to find a way to make this work. Do you have any suggestions.
Thank you,
Paul
-
Hi @pbinnell_2355 ,
The normal workflow for a two-feed package approval is to generally have developers use the
approvedfeed but allow them to use theunapprovedfeed when they need to use a new package or version.However, this shouldn't be their default development style. If they want to use packages that aren't approved, they can request approval for the package(s) they want to use.
This obviously slows down development, but so does code review. And it's a tradeoff in general.
You can use bulk promotion if you'd like. Go to the PAckages page, then select "Cached" from the type of package, then select the packages you wish to promote.
Hope that helps,
Steve
-
That is kind of the process we are looking at but that would mean the developers would update their nuget.config file to access the unapproved feed which would fail on the build server because it can't access that feed. This would lead to there being 2 nuget.config file in use. One for the developers and one for the build server. I'm not sure if you can proxy 2 feeds with one additional feed and that feed would show only the packages available for that user instead of throwing an error if it can't be authorized on one of the feeds.
Thank you,
Paul
-
Ultimately this is going to involve training for your developers. Just like instituting a code review process will be new and uncomfortable at first, a package review process will be the same. Developers will not like it and they will complain.
However, 99% of the time, developers will be fine using the
approvedfeed. 1% of the time (when they want to test a new package or upgrade), then will use theunapprovedfeed. They'll just need to learn how to switch package sources (it's a drop-down in Visual Studio) and then learn not commit commit these package references.My advise is to make it incumbent upon developers to not commit code/configuration that depends on unapproved packages. If they do, then it will "break the build" because the packages aren't available. This is an expected behavior - it would be like if a developer decided to upgrade to .NET9-beta.
"Don't break the build" is a common mantra on development teams, and it means developers can't commit code changes that will do that. Just extend that to using unapproved packages.
