@dean-houston I just upgraded to the latest version and it worked perfectly now. I can update packages of more than 2 GBs without any problems. Thanks you so much!

Hi @pmsensi , Short of using the Native API, I'm afraid we don't have a first-class API to export/import package policies and their related information We may consider adding that after ProGet 2025 is released. Thanks, Steve

Hi @pmsensi , The pgutil builds audit command should show the same license information you see in the UI: https://docs.inedo.com/docs/proget/api/sca/builds/analyze The pgutil packages audit command should also provide similar information on a package level. Is that's what you're looking for? Thanks, Steve

Hello @atripp , Thank you for your help. We have an intermediate certificate (proxy), which I think, as you point out, can be the problem. I will clarify with our IT department. Anyway, after reading a little bit more, there is a variable to force Kaniko to use HTTP/1.1. variables: GODEBUG: "http2client=0" After adding that, everything works :) Thank you! Best Regards, Pedro

@rhessinger I added the requested info to the opened ticket. Best Regards, Pedro

@atripp Thanks for the fast reply and the bypass. Best regards PhilippeC.

Good news @m-karing_2439 , This works in ProGet 2024! More specifically, when rewriting/refactoring the PyPi feed, we added support for this "unconventional" repository - specifically, one that doesn't follow the /simple convention or use any of the JSON/warehouse api. Cheers, Alana

@emer-connelly_2117 very cool, thanks for sharing!!

Thanks for the update @mness_8576; based on this, it sounds like there's definitely a Gateway problem, and that the Gateway is misconfigured / misreporting some error condition from ProGet due to a quirky package request. That's a pretty common thing we've seen as well.

@sebastian thanks for confirming! I've added this as something to fix via PG-2441 and targeted it as 2013.14 (next Friday), but it's a lower-priority issue so it will may get "bumped" to the next or following depending on other issues

Hi @sebastian There is no plan to add user-configurable scheduled job capabilities to ProGet, and it's unlikely we would consider that since they are really hard to support. We do have our Otter product that's designed for that However, in ProGet 2022, we considered a periodic "check" for packages in a feed against the source; the use case was "is a newer patch version available" - and if so, then an issue would be raised about using an out-of-date package. We obviously didn't implement that. But it seems we could take a similar approach and then also check for unlisting/deprecation as well. This might be something that comes up in our ProGet 2024 planning. But in either case, it still involves lots and lots of web calls to check each package against the source - so I would start with a a script and see what you find out. Thanks, Alana

If you're looking for nuget.org-specific metadata, I recommend querying nuget.org directly; of course if you need to work-around internet access issues, you could configure a special feed/connector with no caching. But if you're looking for latest version of a package, the registration API is your best choice. That's what Visual Studio (NuGet client) does for every package and dependency, every time a restore happens.

Hi @atripp, Thanks for the response! It turns out I was overlooking the fact that the docker container cannot access the files of the host. So the directory was non-existent from the perspective of the ProGet instance. I ended up solving the issue by copying my bulk import directory into the docker container itself, which allowed the bulk import service to detect the directory.

Hi @chrisblankde, Can you please tell me what metadata you are trying to update? If it is just the version, you can use the Repackage API. If it is something other than the version, in ProGet 2023, we added the ability to edit the upack metadata directly in ProGet. You can do that by navigating to the package version in your universal package feed and then click "Edit Package" in the upper right corner. If neither of those options works for you, then what you suggested (download/extract/edit/repack/upload) would be the way to handle this. Thanks, Dan

@mness_8576 thanks! We definitely welcome feedback on the UI/UX - this is a new feature, so there's a lot of room to improve :)

Hi @MF-60085, Thanks for the data! We've found that the root cause this time is due to some duplicate rows in the original table, which for some reason was not created with any uniqueness constraints. We'll get this fixed in a prerelease version within a day or two.

I pulled the ci.4 image and that fixed the issue. I haven't noticed any other issues, so I'll just leave the ci version installed until the next ProGet release. Thanks again for the quick fix.

@ade8s_7742 so glad to hear that! It's really rare, but glad it wasn't database corruption!!

Hi @atripp, I just tested the implementation of this with ProGet 2023.1 with the aforementioned atob npm package. The filtering works perfect. The package uses "MIT OR Apache-2.0", and as long as at least one of those two licenses is configured as allowed, the package can be downloaded. Only when both licenses are configured as "blocked", the package is also blocked. This works 100% as expected! When I check the general page of the atob package, "License Information" on the "Overview" tab displays both licenses and their corresponding blocking configurations correctly. However, when I go to a specific version, the version's "Overview" tab will always state This package has a MIT license, and may be used because of configured license filtering policies, even if MIT is actually blocked and only Apache-2.0 is allowed. This only changes when both licenses are blocked (In which case the page states Packages with the MIT license cannot be downloaded due to a global license rule). Looks like this is just optics. As I said, the blocking itself seems to work exactly as expected.