Documentation recommendations for setting up sources (w/ or w/o auth) for projects that run on CI

[rrelyea]

Private NuGet feed:
Don’t you just put a nuget.config file in the project/solution? I see a bunch of questions on authenticating private nuget feeds. I’m assuming we could use buildargs to pass in.
https://www.google.com/search?q=private+nuget+server+authentication&rlz=1C1CHZL_enUS744US744&oq=private+nuget+feed
http://blog.fermium.io/nuget-server-with-basic-authentication/
https://blog.myget.org/post/2012/12/12/nuget-package-restore-from-a-secured-feed.html

Where do developers learn how to customize a private nuget feed? Is there VS tooling? Or, just docs?
I’m also trying to understand how this worked locally and failed in the build environment?

Start of docs:

The recommendation is generally to put a nuget.config at the solution level (or higher up the drive).
There is no tooling to create that, just docs.

And we probably should create something more streamlined in the docs to cover this…

From https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior:

Project-specific NuGet.Config files located in any folder from the solution folder up to the drive root. These allow control over settings as they apply to a project or a group of projects.

Making your NuGet.config look something like this is recommended (clear, then define your source) as a start.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
       <clear /> <!-- ensure only the sources defined below are used -->
    </packageSources>
    <disabledPackageSources>
       <clear />
    </disabledPackageSources>
</configuration>

Then configure all of your sources. If there is an authenticated source, set username and password.

nuget sources add -name MySource -Source http://myNuGetSource -username Tom -password MyPassword -StorePasswordInClearText -configfile c:\nugetExample\nuget.config

(cleartextpassword will work with dotnet.exe restore or nuget.exe restore.)

NuGet.config will end up looking like:

Things to improve:

1. Bootstrapping a nuget.config
2. ClearText password only on dotnet core
3. Docs for this general guidance

[nkolev92]

//cc
@karann-msft @anangaur

[brunobertechini]

Just my 5 cents. The dotnet task build for VSTS should have an option to store user/pass encrypted or use the build account to authenticate.

From MS Docs about nuget+vsts feeds:

We strongly recommend not checking your PAT into source control; anyone with access to your PAT can interact with VSTS as you.

I believe its a huge security risk put your PAT into nuget.config (into source control)

[a-vishar]

Am I correct in my understanding here that my options for CI in VSTS to another VSTS authenticated feed:

1. Store User/Password in NuGet.config/VSTS
2. Store PAT in NuGet.Config/VSTS

Hosted build agents don't have PAT which means that the only option for those using hosted agents would be to store and manage their User/Password in either the config file or in VSTS?

Is there a task we can track for this being resolved either by the building user (for custom agents) or via some other permission mechanism when both the build agent and feed are in VSTS but in two different accounts?

Our current scenario is that we have a feed in account F that we want to access in our build in account B. We use a custom build agent and we do not wish to have the overhead of tracking PAT expiration or updating the username/password in VSTS. Given the build agent is running as a user authenticated in VSTS (account B) can that same auth not be used to access the feed (account F)?

[chris31389]

What about a prompt for login after a 401 is received? Similar to when you git push to VSTS for the first time.

[nkolev92]

Related #6486.

We have done a lot of work to improve the dotnet.exe authentication scenarios in the above issue.

[aortiz-msft]

Issue moved to NuGet/docs.microsoft.com-nuget #1974 via ZenHub