@steviecoaster the Native API should provide access to all of those procs FYI

Hi @michal-roszak_0767, Can you please post what the fix was? Thanks, Rich

@dimas thanks for that! We're currently studying/monitoring the performance for public mirroring, and one "concerning" thing I recently saw was a sqllite3 index file explode in file size. We don't know how that happened, but suspect it might have to do with some "aggressive" testing / request cancellation. Let us know if you spot anything: https://forums.inedo.com/topic/5410/debian-feed-mirror-performance

Hi @lukas-christel_6718, You mentioned that your version had an underscore in it, but the command you referenced does not have an underscore. Is this something that once you add a package with a bad version, then any package fails to install, any version of a package with the same group and name fails to install, or just the specific package with the bad version fails to install? Also, can you please send us the bad version that you uploaded to the feed? Once we have that information, we should be able to reproduce your issue and get a fix out for you. Thanks, Dan

Hi @dean-houston Thank you for the ultra-quick response. Disabling that feature did indeed provide a workaround solution and currently testing is back on track. Thanks again Darren

Hi @rel_0477, Thanks for sending over the reproduction case. I was able to identify the issue, PG-2993, and have it ready to go in the next maintenance release of ProGet. Thanks, Rich

Hi @marc-ledent_9164 , This is available in InedoCore-3.0.4, so if you go to Admin > Extensions, you should be bale to update. thanks, Alana

Hi @mhelp_5176 , I haven't investigated BitBucket Cloud any further, but it sounds like there's an issue with the integration -- and it's definitely something we can look at later. My guess is that it's some kind of change to the API/authentication. But we're all pretty focused on getting ProGet 2025 out the door, so it'll have to be after that. That said, the main difference between connecting to a "Git host" like GitHub, GitLab, Gitea, BitBucket, etc. vs a "generic Git repository" is that there will be some intelligent drop downs to help you select a repository. There are a few other differences as well, but mostly it's UI. So for example, on a GitHub connection, you'll see a list of organizations and repositories, and then would select the one to connect to. Compare this to the "Generic Git repository", where you simply paste in the repository clone url. But in either case, you need to configure each repository connection individually; typically each application will have one repository, which is why this is part of the application creation process. It's definitely not a common practice to be able to "pull in all the repositories in a workspace" at once - that's not really how Git works, and it would involve some kind of script that iterates a list of repositories and clones/updates each one indivdiaully based on configured remotes in subfolder., Cheers, Alana

@michal-roszak_0767 sorry, this is definitely sub-optimal and needs work Basically, when you have API Key Hashing available, there's no way for the page to filter the incoming requests. So, all of the items are shown. It's not really a trivial to fix and requires us to rethink a bit how we are storing/logging this data. We can explore revisiting as part of ProGet 2026.

Hi Rich, I really appreciate you looking into it and confirming the issue so quickly. It's great to know a ticket is already in the works. I'll keep an eye out for the fix in ProGet 2024.39. Thanks again for your help! – Matthias

Your response gave me a hint -- i was just missing the relevant environmental variables from the OCI image. This is now resolved, thanks!

To share with the community some things learned from a private support ticket -- There's currently a defect in the logic where if no packages were downloaded/uploaded to a debian type feed, the in-memory cache is never started. This leads to very long runtimes when running apt update since the response times for the /Release and /InRelease endpoints (from our experience) are at best 1 minute, at worst 10 minutes. The workaround support gave was to manually download a package via http before attempting to use apt. From our experience, this doesn't persist overnight, so it would basically need done daily and truly is counterintuitive to having a package manager like apt.

Thank you. Your comments clarified a few things. I added useApiV3 = $True to the body above, and removed the incorrect use of endpointUrl. The big mistake in the above was Register-PSRepository - I needed to update Microsoft.PowerShell.PSResourceGet to the latest version, and use Register-PSResourceRepository -Name $feed.ShortName -Uri $endpointUrl -ApiVersion 'V3' -Trusted -passthru, where endpointUrl was http://<hostname>:50000/nuget/$feed.ShortName/ Problem solved, thanks again!

Many thanks, Alana! I can confirm, that the proget:24.0.37-ci.2 container image works like a charm Thanks for the quick fix! Fritz

@layfield_8963 no plans, as you're the first to ask :) I don't know much about ARM/MacOS builds.... do you think it's just as easy as adding a new publish target? See our build script here: https://buildmaster.inedo.com/applications/132/scripts/all?global=False

Hi @parthu-reddy , Nothing to worry about - there are a few ways this can happen, and unless it's happening a lot and/or causing problems with your end-users / pipelines / etc., you can ignore the message. -- Dean

Hi @michal-roszak_0767 , I'm afraid Feed Groups are not currently supported in the Feed Management API or pgutil feeds commands. We are considering rewriting/refactoring the API later this year, so I've added this to the notes to consider for that. Thanks, Steve

Hi @caterina, Thanks for bringing this to our attention. I have created a ticket, PG-2990, to track the fix and it should be released in the next maintenance release on June 13th. Thanks, Rich

Hi @sgardj_2482 , ProGet's Integrated Web Server already supports Windows Integrated Authentication (WIA). Actually it supports WIA better than better than IIS in that only the Web UI and supported feeds (or ones you configure) will do the WIA challenge. Behind the scenes, the Integrated Web Server (IWS) uses Kestrel unless you're doing so-called "port sharing", which would be having two web applications sharing the same port. That's becoming less and less common, and isn't something Microsoft recommends anymore. If you bind to a host name in IWS (i.e. port sharing), then the operating-system level HTTP.SYS component is used. That is much less flexible with WIA and every request must be authenticated. Which means it'll never work with Docker, npm, etc. So it's not recommended. Thanks, Alana

Hi @michal-roszak_0767 , 401/403 are not logged, so you won't see a server side event. 403 means authentication was successful but the permissions are not OK My guess is that the wrong feed or credentials are being specified. Like maybe using an API key? Thanks, Alana