@mathieu-belanger_6065 said in Connection reset while downloading npm packages: I am curious, would there be an impact on performance when "piping" connectors together? For example, internal feed A has a connector to internal feed B, which has a connector to internal feed C, which has a connector to npmjs.org? Connectors are accessed over HTTP. So assuming you have a "chain" like A --> B --> C --> npm.js, (i.e. different 3 feeds and 3 different connectors), each request may yield 3 additional requests. So when your browser asks feed A for package typescript@3.7.4, then following will happen. If the package is cached or local, the file is streamed to the browser Each connector (just B, in this case) is queried over HTTP for typescript@3.7.4 The first connector that returns a response, the response body is streamed to the browser Each connector follows the same logic. When ProGet (via a request to feed A) asks feed B for that package, the same logic is followed: If the package is cached or local, the file is streamed to the browser Each connector (just C, in this case) is queried over HTTP for typescript@3.7.4 The first connector that returns a response, the response body is streamed to the browser Continuing the pipe, when ProGet (via a request to feed B via a request to feed A) asks feed C for that package, the same logic is followed: If the package is cached or local, the file is streamed to the browser Each connector (just nuget.org, in this case) is queried over HTTP for typescript@3.7.4 The first connector that returns a response, the response body is streamed to the browser This is why caching is important, but also why chaining may not be a good solution for high-trafficked npm developer libraries like typescript. The npm client basically does a DoS by requesting hundreds of packages at once. Same is true with nuget.exe as well.

The two api endpoints I can think of are: /v2/_catalog returns all repository names ("container" names) /v2/<repository-name>/tags/list returns all tags within specified repository Some more details are here: https://docs.docker.com/registry/spec/api/

Hi @Adam1 , The Restart-Server operation is performed on the server itself, using the Inedo Agent or PowerShell Agent. Behind the scenes, the agent will just use the advapi32.dll::InitiateShutdown Win32 API method, and that error string indicates that Windows is returning ERROR_ACCESS_DENIED when attempting to initiate the Shutdown. This is the same method that shutdown.exe uses behind the scenes as well. So basically, just make sure that the agent process is running as an admin/system account. Best, Alana

@Joshua_1353 did this work in Otter v2? The "too many redirects/auth requests" is usually a kind of red herring, and refers to some sort of configuration problem (corrupt local repository, cached credentials, etc.). We'd need to see the whole stack trace --- but could you post it to a new Topic, so we can track it differently? I don't think it's related to v3. The reason it didn't show in v3 was (we just forgot to tag it properly after some coding refactoring changes in Otter).

Hi @sonismile10_4270, BuildMaster only supports Visual Studio Test (formerly MSTest), nUnit, and jUnit out of the box. I'm not very familiar with SOAP UI, but I think your best bet would be to use Soap UI's jUnit integration and then run the jUnit tests to track them in BuildMaster. If not, you would probably need to build a custom BuildMaster extension to support this. Please see our unit test documentation for more information. Thanks, Rich

Hello @rhessinger, I did the changes to use API v3 in the future. I still get exceptions that max pool size was reached. But here v2 API is still in use. I have to change this also. After that I will monitor again and come back here. Thanks

Hi @Stephen-Schaff_8186, Thanks for the clarifications! In fact, I wanted to learn some of the behavior, and here's what I discovered. I'm sharing the details, because I think we should take the opportunity to clarify not only the docs, but the UI, since it seems like this can be improved. It's a new concept in ProGet 5.3, and it was primarily intended to guide set-up of new feeds, so we haven't looked at it closely since first adding the feature. Feed Type Sets There are two sets of feed type options, and which ones are displayed is dependent upon whether the feed type is denoted as having a private gallery (HasPublicGallery). HasPublicGallery == true "free/open source packages" "private/internal packages" "validated/promoted packages" "mixed public/private packages" HasPublicGallery == false "private/internal packages" "validated/promoted packages" These all map to an enum: Mixed = 0, PrivateOnly = 1, PublicOnly = 2, Promoted = 3. HasPublicGallery The following feed types are denoted (internally) as having an official, public gallery: Chocolatey, Cran, Maven, Npm, NuGet, PowerShell, Pypi, RubyGems. Helm and Docker are not on this list, perhaps because there's no official gallery? I'm not sure. Debian and RPM are not on this list, because I don't think they support connectors Feed Type Behavior Almost all of the behavioral changes occur in the "out of box tutorial", to guide users through the setup. Aside from that, here's the UI impact I found: FeedType == PublicOnly On the list packages page (e.g. /feed/MyFeed): the "package filter info" is displayed as "Unfiltered", even if no package filters are configured to bring visibility to the importance of package filters the "vulnerability status" is displayed as "Not Scanned", even if vulnerability scanning is not configured On the Package Versions page (e.g. /feed/MyFeed/MyPackage/versions): the "vulnerability status" is displayed as "Not Scanned", even if no vulnerabilities are detected FeedType == PrivateOnly Feed allows AllowUnknownLicenseDownloads, regardless of global setting; this feels like a big behavioral change, but it makes sense, since why would you license your own packages, etc. The Manage License Filter page displays an error. On the Package Overview page (/feed/MyFeed/MyPackage/1.2.3), the license information box is not displayed On the List Package Versions page (/feed/MyFeed/MyPackage/versions), the license information box is not displayed FeedType == Promoted On the List packages page (/feed/MyFeed), the add Package Button is disabled FeedType == Mixed No UI changes. Next Steps? Well, that's everything. Any opinions / suggestions? I'm not sure why the Add Package button is disabled. Of course you can still use API, or even navigate directly to the page. Perhaps a warning on the Add Package Page would be better? Cheers, Alana

This upgrade path isn't supported, and ProGet 5.0.1 does not work on SQL Server. Your best route for upgrade is ProGet 5.0 > ProGet 5.3. Then, migrate to ProGet for Linux.

Hello; That search syntax is really only supported by NuGet v3 API, I think; so, ProGet simply forwards on the query to that API, and returns the results. But regardless, connector filters need to be applied after the remote feed returns results, because connector filter logic can be more complex that what is supported by the various feed APIs (you can allow Microsoft.* and Inedo.* for example). More advanced connector filter options are definitely something we've considered, and we'd love to do things like "version: 3.*" for example. But, it's a lot more complicated under the hood, and probably isn't even feasible given the nature of feeds. Alana

I had such problem with localized account with a lot of software :) Managing the [Otter / Buildmaster / Proget] service Account from the InedoHub would be nice. Philippe

Hey @atripp I know this is still a beta. Happy to help you Philippe

Thank you for the response and the incredibly fast fix! I will get my instance upgraded and test it out. Thanks again!

Thank you! Will do.

Hello; I'm not sure if we can help here, this sounds like something more appropriate for Azure DevOps community.

@andrew_5903 thanks, I'd like to update the docs! Did you end up writing a script to just call that for each Jar+Pom in your directory?

Hi @Crimrose, Thanks for posting a follow-up solution for this! I'll keep this in our notes incase this comes up again in the future! Thanks, Rich

ProGet does not support package-level permissions; you would need to create separate feeds, or create a custom package filter (in C#) that could have some sort of filtering logic per user.

Hi, i'm running into this now in Version 5.3.17 (Build 19). All of our packages are internal use only and i don't want to bother with setting up license rules. Can i disable the license checking?

Hi @Crimrose, this would probably be better to check on the Chocolatey forums / community site. But if you can find the answer, please share it :)