@atripp @joshuagilman_1054 TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that... [System.Nullable``1[[System.Int32]]] [Nullable[int]] ... much easier to read

@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

Hello, That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work. Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc). Alana

Hi @JonathanEngstrom, You can find a list of the available arguments in the InedoHub CLI documentation. Hope this helps! Thanks, Rich

@saml_4392 in theory it's fixed, but we didn't test it Could you open a new thread about a creating a Helm chart for ProGet itself? That'd be a great place to start that discussion, and get community direction and feedback from users - and provide nice opportunities to partner with organizations like bitnami, who could help

Thank you

Ah, I see what happened. The logic to display that particular should be tab BuildMasterConfig.Legacy.ScmTriggers || BuildMasterConfig.Legacy.UrlTriggers. I fixed it! FYI - we still ship new maintenance releases of BuildMaster 6.1, but no "new features". The main goal is to make sure we have everything to help transition the migration to 6.2/7.0, so if there's anything we can add please don't hesitate to ask.

Ah yes, thanks. Time to configure that side of it then.

Can confirm the latest version resolves the issue. Thanks!

Looks good! I had to create a volume mount for /var/proget/extensions to get the extension upgrade to persist, but it seems to fix the problem. Thanks!

FYI @alexjeffreys_3320 this is currently targeting 5.3.26, which is planned for April 2 (PG-1914) - we'll update if it gets tricky or problematic

I didn't have the problem the next day, so I can no longer replicate it. If it happens again, I'll re-post with logging details. Consider it closed. Thanks.

@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

Hello, All good, thank you for the support, the investigation and the oncoming fixes. Cheers, Jérôme

@emejibka_8689 got it, thanks! So, ultimately, you were able to get it working by adding that? I'd love to get a NGIX Guide together that walks through how to do this. What did your NGIX configuraitn end up looking like?

@stevedennis Thanks

Great !! Thanks

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