Topics created by Stephen.Schaff

Hi @Stephen-Schaff , what you're doing should work, but this appears to be a bug due to the special-handling required for docker image promotion via API - so I've logged this as PG-1939 - we should get it fix in the next maintenance release.

@Stephen-Schaff let us know! If that works, then we can just inject that in the package, and read it in on the history page, similar to this NuGet package: https://proget.inedo.com/feeds/NuGetLibraries/Inedo.ExecutionEngine/100.1.1/history

OK. That aligns with what I was seeing. Thanks for explaining it to me!

@rhessinger You may also want to remove this message: The big red banner is what got me looking into the license types in the first place. (I did not want my users to see the big red banner and I could see no way to suppress it except for getting a license assigned.)

@Stephen-Schaff Very glad to hear! It makes absolutely no sense makes that Managed Pipeline Mode would have any impact on how these libraries behave... but there you have it. These libraries are ancient, and even Microsoft has no idea how they work anymore. Apparently Microsoft is working on shipping brand new libraries (no COM interop magic) in .NET6, which means by .NET8 they just might be usable, and then perhaps in another decade they won't require mysterious changes

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.

@Stephen-Schaff I think cc/ @rhessinger can correct me if I'm wrong, but you should be able to just rollback only the the InedoCore extension to 1.7, where we used the older version of the AD libraries. You can do this by downloading and manualy installing from here: https://proget.inedo.com/feeds/Extensions/inedox/InedoCore/1.7.12

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.

@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

@Stephen-Schaff said in Feature Request: Limit Container Images to those that are inherited from another feed: It is possible that you are underestimating the value that enterprises place on governance of their processes. It's really valuable, but from a marketing/sales perspective, it's hard to "compete" with the likes of ServiceNow for governance improvement. Containers are already too much in the weeds for the folks with governance problems/pain points... and they can "just throw a guy they trust to manage the details, like Stephen" @Stephen-Schaff said in Feature Request: Limit Container Images to those that are inherited from another feed: Multistage Dockerfiles to not pass any part of the Dockerfile that was used from a previous stage on to the later stages (aside from any files copied). That makes sense, but you could still validate that containers "inherit" from a known base image. In ProGet, you can navigate across base images.

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/

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

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