OK, I did a bit of looking around and ProGet is currently very well priced compared to its competitors. I can easily buy two servers of ProGet for the price of single a JFrog license. If needed, I could try to use that to convince my Management to purchase a second production license for use as a Sandbox instance.

@jn_7742 unfortunately, Microsoft has also abandoned Source Server in favor of SourceLink, and they will not add Source Server support to Portable PDB files Technically, ProGet's Source Server works on Linux, but since ProGet can't inject its Source Server urls into the .pdb files, it's impractical to use. I'll let you guess which 20+ year old program is required to inject Source Server metadata into Microsoft PDB files Bottom line, you'll need to upgrade your processes to use SourceLink

I think I have an idea of what is happening here. I think that this issue is actually caused by my other open issue: https://forums.inedo.com/topic/3164/user-seen-as-a-group I noticed that when I am adding any service account user, it is added as a group instead of a user. Actual users do not have this issue. In fact if you look at step 4 in my reply on Feb 12th, you will see that the restriction added shows the user as a group (purple background). Lets suspend this issue until the we have figured out the issue with users being added as groups.

Hi. It's OK to continue with the ticket only.

Unfortunately this is just an invalid package... someone really needs to tell the developers at Microsoft that the developers at Microsoft really want packages to be in SemVer2 format, per the Microsoft documentation https://docs.microsoft.com/en-us/nuget/concepts/package-versioning Microsoft's documentation seems to no longer describe what Microsoft's once documented "legacy versioning" used to be, but we captured it in our documentation before Microsoft removed it. Bottom line, the "." is an invalid character in a non-SemVer2 (i.e. four-part version number) pre-release tag. Hence, why it's getting a 400 error. It used to do that on NuGet.org, too. I guess it doesn't now. We probably won't change this, since it kind of works already., and since it's only one package. But if you email the Microsoft team responsible for that package, they probably will just change their versioning going forward. IT'd be nice if Microsoft documented how their non-SemVer2 packages are supposed to work.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Hi @scroak_6473, ProGet automatically handles creating a temporary API key for use with clair. When ProGet integrates with clair, it generates a temporary key to use to check layers for vulnerabilities then deletes it when the process completes. So there is nothing you have to do to authenticate clair to ProGet. If the key is still there after running the scan, my guess is an error occurred while trying to clean it up. As for the other error you are seeing, are you able to pull an image with that layer attached to it? I can probably create a SQL query for you to link a layer to the image if needed. Thanks, Rich

@philippe-camelio_3885 oh i see; you mean, capture the output of a process or script execution into a variable or something. Definitely something to consider as an enhancement, I think. That wouldnt' be too bad (though the variable could get huge, and rutnime variables raen't realy designed for large amounts of text like that)

Thanks for the update; and the upcoming fixes will certainly make it so that purging is much more efficient on the manual execution side, just in case there's an "Explosion" of executions like this. So right now, my concern is that it's "logging every sync" (once per hour), due to a sort of bug or something. Can you check what's getting logged in Infrastructure Sync? You should be able to see this under Admin > Executions, and see if you can spot a pattern? No rush. The infra sync executions should clearly show a change history of what was updated on the infra side.

Ok Thanks for the reply

@atripp You bet. I'll see what I can do and let you know

@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.