Error on Private Source (AzureDevOps) #542
Comments
|
The best way to manage sources is to have a e.g. mine contains <packageSources>
<add key="MyCo" value="http://packages.MyCo-internal.com/nuget/Default" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>I'm not sure why your internal feed is not working, with the same url that nuget uses, and protocol version 3, you should be good! |
|
Is it related to this issue? I looked up the error message "Nuget Unable to load the service index for source” and got a lot of links about proxy settings. |
|
So we do have a NuGet.config with our private source.. I have added the nuget.org source, to the file and committed it to the repo, but it didn't seem to have any effect. Should I still pass in the 2 source parameters here? Thanks! |
|
What are you using for your nuget feed? If it's Azure DevOps Artifacts I had to do this little dance to get it to use credentials from environment variables: |
|
If you have the If you set log |
|
Detailed Output when it works!! (just nuget.org source)
|
|
Detailed Output when it doesn't work:
|
|
@slang25 thanks for your help!! could you let me know what commands you ran to set your PAT, or did you just add a username and PAT to all of your nuget.config files... (would rather not have to do that) |
The sources are being read from config files correctly. It's going wrong after that :( So the second feed Url for the private source is on |
|
@JBoothUA I didn't run any commands as this was a build I was getting working in AppCenter, but I suspect you'll want to do a similar thing. If you are kicking this off from Azure DevOps build pipeline, you can configure environment variables in the ui, and you can store the PAT token in "Secure files", so it remains a secret. |
|
@slang25 so you're recommending I add this to the nuget.config Or should I use the name of my PAT token variable? Still having problems here, @AnthonySteele any other ideas on how I could troubleshoot this? |
|
It's up to you really, if you already have an environment variable containing your PAT then you could use it in place of |
|
@slang25 ok cool, that is good to know. But it didn't seem to have any effect still.. |
|
Odd. Be sure you have the necessary permissions granted on the PAT, here's mine: |
|
Ah, it appears the key is not |
|
We might be able to make this functionality in the NuKeeper extension because we can insert the build agent pat there. Might be worthwhile if other people run into this issue as well. |
|
Thanks @MarcBruins I'm still struggling with this issue. I feel like @slang25 has me on the right path, if I use those settings I can get the error to change into a 401 unauthorized error.. And on the latest master I can even get it to complete the process, of course my fear is that it will never attempt to update the packages from my private feeds... So unfortunately this is still an issue for me. I do not have any problems with my Azure DevOps private feeds except with NuKeeper, so it's hard to tell if I have something configured poorly or if NuKeeper could be doing something to make my life easier. |
Of course my fear is then that it will never update those private packages it threw the 401 error on. |
|
@JBoothUA, can you try the following nuget.config, we are using a custom package source as well and it works for us <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
<add key="Galileo" value="https://hexagon-si-gpc.pkgs.visualstudio.com/_packaging/Galileo/nuget/v3/index.json" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSourceCredentials>
<Galileo>
<add key="Username" value="VssSessionToken" />
<add key="ClearTextPassword" value="{HARDCODED_PAT}" />
</Galileo>
</packageSourceCredentials>
</configuration> |
|
I think my comment from the previous discussion is still valid... To authenticate to a private feed you might look at Using dotnet with Azure Artifacts which recommends using the Azure Artifacts Credential Provider Also, it might be worthwhile looking at the source code for the NuGet task to see how it achieves it, some of the parameters are similar to what we need e.g.
|
|
@phatcher I tried to look at the credential provider, but I guess I didn't know what I was doing |
|
@shep1987 no luck.. thanks for the advice though.. is the VssSessionToken something that is built in? maybe I need to set that up somehow? |
|
@JBoothUA The use name for the package credentialst can be anything |
|
Our dev team standardized on "user" level NuGet.Config that contains the private source for AzureDevOps NuGet feed (and authorized credentials). We do not commit any NuGet.Config into source control. This works well since a developer can easily restore any / all repos from their user level NuGet.Config file. When building on Azure DevOps, as mentioned above, we can easily use the built in dotnet restore task to restore from the private feed. As the thread suggests, this makes it also very difficult for us to run Nukeeper on any of our repositories. Typically most NuGet applications / integrations we work with all support the idea of a machine or user level configuration for NuGet.Config. Is it possible for Nukeeper to support this as well? Additionally, it may benefit this thread allowing you to easily configure the authorization for your Azure Private DevOps feed at the user level for local usage, and could configure Nukeeper inside a docker container (or private build servers may be configured at the machine level for private feeds) to execute on the build server (with a NuGet.Config at the proper location). Example local user level path (windows): C:\Users{username}\AppData\Roaming\NuGet\NuGet.Config |
|
NuKeeper uses NuGet own libraries to resolve and parse the nuget.config files, there's nothing custom there, in the sense that you should be getting the same sources resolved as NuGet/dotnet core would. Check the output of a verbose run, the probing paths should be listed near the start of the log. |
|
Hi @skolima thanks for the help!! Here is the start of my log, could you point out what I should be looking for here?? I verified the same errors happen on my peers machine.. None of us have any issues pulling or publishing to our AzureDevOps artifact feeds, but there must be something that we're missing that makes it all work that NuKeeper isn't aware of??? Here is the log, after this I just get the same error repeated over and over: C:\Users\jbooth1\Source\Repos\NuKeeper [master ≡]> dotnet run -p NuKeeper\NuKeeper.csproj -- repo {REPO_URL} { PAT } --source https://hexagon-si-gpc.pkgs.visualstudio.com/_packaging/Galileo/nuget/v3/index.json --maxpr 5 --consolidate --verbosity detailed |
|
Hey @JBoothUA You just posted your PAT please revoke it asap |
|
i caught that too, thanks! |
|
In case this helps any, here is the start of the output for the same command, except here I specify nuget.org as a source. this works much better. I'm starting to think that it might be related to what @travisgosselin mentioned in his comment above. All of our devs do add our private feed to Visual Studio's Tools -> Options -> NuGet Package Manager -> Package Sources.. Maybe adding it to VS in this manner is doing something for our local machines that NuKeeper doesn't know to look for?? Just guessing at this point... C:\Users\jbooth1\Source\Repos\NuKeeper [master ≡]> dotnet run -p NuKeeper\NuKeeper.csproj -- repo {REPO URL } { PAT }--source https://api.nuget.org/v3/index.json --maxpr 5 --consolidate --verbosity detailed |
|
My bad. If you include |
|
For my current project we use NuKeeper in the build pipeline and also have a private nuget feed. I've tackled the issue by using a token replace task and then using the NuKeeper task:
For more info on the Replace token task The Nuget.Config is straightforward:
|
|
Is there anything simple that NuKeeper can do to make it easier to plug these tokens into the urls? |
|
I can also confirm that Nukeeper does in fact seem to be reading my Windows / user level NuGet.Config properly for authorizing against private feeds. However, my main use case is to have this functionality of using the machine level NuGet.Config inside a docker container.... which it never seems to pick up (not sure if this is a container or a linux issue specifically). |
|
Ok have made some progress.. By using https://github.com/Microsoft/artifacts-credprovider/ I can get However i can get round all these problems by adding: <packageSourceCredentials>
<Galileo>
<add key="Username" value="VssSessionToken" />
<add key="ClearTextPassword" value="{HARDCODED_PAT}" />
</Galileo>
</packageSourceCredentials>to |
|
@shep1987 I think you're right on the money, I was able to put that in place and run without any of the errors!!! It appears that I have to put that information in the %appdata% config as well as the nuget config inside of the repo. But I was able to get rid of the errors!! |
|
Took it to my final test case... Using the And I am still getting an error (although this one is new..) it does appear to have helped! If there is anything you can do to make it easier, where I dont have to put the credentials in the %appdata% AND in the NuGet.config that lives in the repo, that would be helpful. Also if the PAT is included in the NuGet.config files does it have to be a required command line arguement? I guess it is supposed to not be required if it is set to an environment variable, but that doesn't seem to be the case (unless I'm using the wrong env var) But I think it is very close!! Now I'm getting an issue that seems to have been open before: "Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory." I tried adding the flag to the end of the NuKeeper command but it didn't appear to be a valid NuKeeper argument. Update the %appdata% nuget.config did get rid of the original errors! So now I'm on my very very final test case! Here is the issue I'm getting: |
|
I know it's a bit old; But I'm facing exactly the same issues. I have the hard-coded clear text password in both the repo-root located NuGet.config and in the Any suggestions would be very welcome. |
|
I've added PR #868 to resolve the issues i had with this - auth issues mainly. With that, I can update NuGets against our Azure Artifacts repo perfectly. |
|
@ransagy do you have any idea when this will be merged? |
|
@Bene2205 That's a question for the maintainers, I'm afraid. I've been using it since and haven't noticed any issues, but i only test this scenario at work - So i don't know if anything else is impacted. |
|
Until #868 possibly fixes this issue, I've added the following step in my Azure Builds Pipeline which writes a new NuGet.config file containing the system's access token. I simply overwrite any existing NuGet.config (mine isn't getting picked up, which is another issue: #907). |
|
I had good luck by adding the NuGet Authenticate Task to my pipeline to solve this problem https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget-authenticate?view=azure-devops I just started using NuKeeper today, so I wouldn't call this fully baked yet and might not follow all the best practices, but if I don't throw this out there now, I will forget to. I can say that the NugetAuthenticate task let me hit my own Azure Devops package feed Here is the YAML file I ended up using: |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I'm having similar problems. Since the new version:
I'm not running behind a proxy as far as I know, I'm connected to my corporate network through a VPN however. Even so I've tried all different combinations of my plaintext password, PAT (with all scopes), username, domain name for both We recently upgraded to Azure Devops Server 2019 from an older TFS2017, and just this morning I had some issues with cloning repositories that was solved by not using the |
I have a working example of AzureDevOps "repo" command!!!!
So sweet!!! Talk about automating teadious workflows!!!!!
However, I seem to always have the same issue when trying to pull from my private repo.
I'm currently pulling the very latest master and running it, with great success, until I add our private feed as a --source parameter or add it to the nuget.config
At which time I always get a chunk of errors. I'm sure I am missing some sort of configuration, but I have tried to set my environment variables as far as I know... Maybe I missed something, I also am not sure if my env var credentials are correct since I'm using AzureDevOps..?
I basically get the same error over and over for each of my packages:
Maybe there is an issue with passing in multiple sources with --source --source? It's almost like I'm passing in no sources now?
Here is the command I am running:
dotnet run -p NuKeeper\NuKeeper.csproj -- {URL} {PAT} --source https://api.nuget.org/v3/index.json --source https://hexagon-si-gpc.pkgs.visualstudio.com/_packaging/Galileo/nuget/v3/index.json --maxpr 5 --consolidateAgain this works fine if I only use --source and with the nuget.org feed, but as soon as I add my private feed all of my commands throw this error, also if I ONLY use my private feed it throws the same type of errors.
Although this linked issue is closed now, I was adding information at the end that seems to still be a problem, so it seems it could still be related to my issue:
#386 (comment)
That link also contains a lot of my configuration files, etc. but please let me know whatever would help troubleshoot this!! And of course I'd be happy to include any helpful information on this thread also.
Thanks for everything!! So close to getting this working in production!
Hexagon has over 18,000 employees, and I hope to spread this all over the company!!!
And to others!!
If we can get this last bug fixed I will forever be in your debt.
Please let me know if you need any screenshots or tutorials for Azure DevOps and NuKeeper I would be happy to help with anything!
The text was updated successfully, but these errors were encountered: