Hi @mike_2282, Thank you for the feedback. I have made some changes to the documentation to address most of the issues you have brought up. Thanks again for the feedback! Thanks, Rich

Alright, after messing around with that information, I was able to get it to work. I am able to update the variables. Interesting thing is that it doesn't appear I can change just one variable, I have to change all of them, or at least enter all of them as they are? Thanks for your help!

Thanks for the additional debugging information; we now see why this doesn't work. It would appear that NuGet stopped streaming all versions of the packages at some point, and now appends the following at the end of its package search XML... <link rel="next" href="http://www.nuget.org/api/v2/Packages? $filter=tolower(Id)%20eq% 20'ravendb.client'&$orderby=Id& $skiptoken='RavenDB.Clie nt','RavenDB.Client','1.2.2005-Unstable'" /> So, we will need to add support for this as well... I've added this as PG-140, but it's not scheduled for a release yet. If an enterprise (i.e. paying) user requests this, we can expedite it of course.

Hi @gurdip-sira_1271, Yes, this will be released with Otter later today. Thanks, Rich

Please review KB#1161 for instructions on how to update this.

Hi @aries66_2180, I just set up a clean ProGet 6.0.16 docker instance and tested this and it seems to be working for me. Can you send me an example image you are trying to push that fails? Also, would you be able to use a tool like WireShark or Fiddler to record your requests when trying to push an image and email it over to us at support@inedo.com with a subject of [QA-878] Docker push error? Thanks, Rich

We take problems very seriously, but we need to prioritize where to spend engineering resources tracking down problems. This was a edge case that we could not reproduce, and had a very minor impact, and only affected a very small number of free users with a very specific configuration; a free user was able to track down the underlying cause and we fixed it.

We haven't heard any other complaints, so it leads me to think it's either your end (proxy?) or npm's end (blocking). We have no idea what their blocking mechanism could look like. For all we know, they could be doing agent-string filtering, and blocking requests from ProGet software, but not your web browser or npm client. Best bet is to run ProGet through a proxy (like fiddler or wireshark), by going to Admin > Proxy. Then you can see exact traffic.

Hi @pfeigl, Thanks for letting us know. It looks like this is related to how HEAD requests were handled. I went and added that header to head requests also. This will be tracked in PG-2300 and will be released in ProGet 2022.25. Thanks, Rich

Hi @marc-ledent_9164, Ah, thanks for the extra details here. I was finally able to recreate this issue. I'm tracking the fix in BM-3770 which is expected to release in the next version of BuildMaster, which is due out this week. Thanks, Rich

Hey @dan-brown_0128, And of course, the other issue with using SHA Digests is that they are unsortable/unordered, and there's no way to know if you're on an "newer" or "older" version. Git inherently has this same problem -- and users who try to name packages after commit hashes quickly learn how poorly that works :) Looking around, it does look like some registries actually support immutable tags (Ex ECR, Harbor). Some tags make sense to be excluded from immutability - like latest since those are dynamic by intention. ProGet's tags are effectively immutable -- in that you need the overwrite permission. But we also have the Semantic Container Versioning, which takes it a step further and enforces tags. Unfortunately, a lot of users don't use this feature or follow our guidance - and they end up with all the predictable headaches. As an engineer, I'm obviously offended in principle by these bad practices, but more practically... the consequences of this kind of misuse/abuse is Tool Blame. And that means we look bad and don't get a renewal. So, my philosophy/approach as a product vendor is "provide a good solution", not necessary "enough rope to hang yourself". As I mentioned before, OCI Repositories are poorly-designed solution to a misunderstood problem -- and my read is that it's going to be a passing fad. Cheers, Alex

Good news

Hi @scusson_9923, Glad to hear it! Thanks for following up as well! Thanks, Rich

I'm directly executing the DashboardFeeds view, so I'm not using the parameter. It seems that the SUM([Package_Size] for [Feed_Size] and [Cache_Size] are the culprit. When I replace the query with [Feed_Size] = 0, [Cache_Size] = 0 then the timeouts are gone! They are just missing from the feed disk usage graph. Adding an index to NuGetPackageVersionsV2.Package_Size didn't help. The strange thing is that some pages that are not using the graph are also executing the DashboardInfo stored procedure.

@atripp Thanks, I installed 23.0.10 this morning and the git checkout task succeeds on the RedHat server. Next step is getting the docker build task to succeed. I may open a separate post for that.

For completeness, v3.0.3 was just published which adds an index to Publish_Date and the dashboard query now returns virtually instantly tested against 100,000+ packages in the database.

Hi @claudio_9251, I'm not too surprised by this. NuGet has deprecated many of it's ODATA( v2) endpoints which has caused some issue within ProGet, we have documented this in our NuGet v2 troubleshooting guide. It is very possible that Telerik (Progress) has not made these changes on their end which may be causing this. This is especially true when it comes to connectors because ProGet will pass through a lot of the V2 queries the client makes to the remote endpoint. Either way, the NuGet v3 API is the proper API to use going forward and we highly suggest using that. Thanks, Dan

Just wanted to let everyone know who's affected by this that we have a fix in 3.5.0. It's officially classified as a beta version, but only due to some database schema changes. The release notes and download links are here: http://inedo.com/proget/versions

Unfortunately we're not able to diagnose this with the information you provided. That error really doesn't make sense in the place it's happening. Can you please submit a ticket with: Configuration Variables defined at various levels (System, etc) Plan as OtterScript Pipeline as JSON Full Execution log, including the full stack trace you sent

Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know. But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that. There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.