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

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 @steviecoaster, Thanks for the find. We'll get this fixed in the next maintenance release. 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, Can you please post what the fix was? Thanks, Rich

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

Hi Fritz, We appreciate the feedback on this! ProGet 2025 will indeed have a separate dedicated mount for the database, but we didn't include this in the preview. As to the other issues, yes we do have a supervisor that attempts to start postgres and perform a clean shutdown on container stop... but there are some bugs we are working through, likely made worse by the ownership issues you discovered. These concerns will absolutely be addressed before launch. Again, thanks for trying it out and please let us know of any other issues you find or suggestions you may have! -Greg

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!

Late reply (was out at a conference), but this was in fact permissions related. I've added a check to ensure the Inedo service account has been granted modify permissions on the drop path upon creation, and it is working appropriately!

Hi @parthu-reddy , This looks more related to Server Overload / Database than anything to me. Note how all the requests are coming in at exact same second. Can you throttle your load balancer a bit, so they don't all hit at the same time? Even a slight delay will help. FYI - we are tracking a recent regression to SQL Server analysis engine (???) that is causing one particular query (NuGet_GetPackage) to go incredibly slow under extreme traffic. For some reason, it's using the wrong plan suddly. It's been happening to a few users after a recent upgrade/patch to SQL Server. We have a work-around but would like to test it in the field against a user. Thanks, Alana

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

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

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

I've now found a cleaner way of adding this entry to the host file... If using docker run, add the argument: --add-host=<host_server_name>=127.0.0.1 if using a docker compose file, add an entry: extra_hosts: - "<host_server_name>: 127.0.0.1"

Great, thanks!

Hi @steviecoaster , You can use pgutil for this: pgutil settings set --name=Licensing.Key --value=XXXXXX This is in the Configuration table FYI, which is what pgutil settings does Thanks, Steve

@michal-roszak_0767 said in Pull Maven artifacts - invalid version: Next victim: https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/ jeeze, what a mess! Well, there goes any hope of using v[0-9]+ -- they just straight up use random strings as version numbers. https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/. https://repo1.maven.org/maven2/org/springframework/data/spring-data-releasetrain/Neumann-SR9/ Open to ideas, but based on the URLs alone... I don't see a good way to identify one of these as an artifact and the other as a version of an artifact.

@michal-roszak_0767 it wouldn't hurt to start a new topic about it, but it's design decision so you'd have to make a good use case for it :) I can't find the discussion (maybe it was internal), but the idea is that "generic website connectors" for Asset Directories are a poor solution for "offline" environments. A "generic proxy" like ngnix will always be better in every way.

Hi Steve Thanks for your response. I've read the documentation and for the client part I followed the Microsoft documentation: https://learn.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg After some testing, I've found the problem: I had to add /v3/index.json to the URL. Now the package and the symbols are pushed to the server. The ProGet UI shows the correct URL under API endpoint URL:. I'm not sure why my build script was using the URL without v3. Maybe it was different in an older version of ProGet or I just made a mistake somewhere? Interesting is that pushing "worked" when using the URL without v3 and v2 API disabled for the feed. Maybe the client NuGet client contains some logic to only push the snupkg file when it detects a v3 source?