@philippe-camelio_3885 oh wow, great find. Hmmm..... so I guess that must be some kind of UI bug with not trimming the newlines variable.ListValues = variable.Type == VariableTemplateType.List ? txtListValues.Value?.Split(new[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries) : null; I'm sure this should be fixed eleswhere too, but for now I'll just add | StringSplitOptions.TrimEntries and I guess that will at least fix the UI bug

@Dan_Woolf Thank you I've now produced a dashboard using this API to show my GREEN/RED status without requiring a login. I know its a lot to ask but adding dashboards public would be amazing in Otter. My code is only about 6 lines but not sure how much effort this is to add into Otter.

Hi @ssuenaga_1020 , Thanks for the detailed report; this seems easy enough to fix, so we'll get this addressed in the next maintenance release (2023.20) via PG-2499. Cheers, Alana

Hi @e-rotteveel_1850, Thanks for reporting this; we'll get this fixed via PG-2498 in ProGet 2023.20 (in two weeks). Cheers, Alana

Ahh that could be it, I will update to latest version and try it again :)

Sorry for my late reply, but we have since installed version 2023.16 and repodata.json works perfectly fine now! Thanks for including this in your updates.

@lucas-almeida_8120 it's hard to say; it's likely due to some kind of operating system configuration or issue that's preventing the service from restarting. We haven't seen this happen very often, and restarting the web is not a common activity. It's probably not worth spending time investigating or trying to resolve, especially given the age of the server. You'd probably have to look at the Windows service logs to find what the issue might be.

Hi @hashim-abu-gellban_3562, I see a few issues here... First, the URL you're using is not correct; the easiest way to to find the url by clicking the "download package link" in the ProGet UI. It will look like this: /nuget/your-feed-name/package/your-package-name/your-version-number Second, you're downloading a file - so you want to use a powershell command like this: $url = "https://myprogetserver/feeds/mynuggets/package/mypackage/1.0.0" $destination = "c:\mypackages\mypackage-1.0.0.zip" Invoke-WebRequest -Uri $url -OutFile $destination Best, Steve

@jw thanks for the bug report! We'll get this fixed in the an upcoming maintenance release via PG-2491 :)

Hi @caterina, Here is the final solution: When using the auto type and scanning for NuGet and npm dependencies: The default configuration should be to omit dev dependencies and scan the node_modules directory When using the npm type and a package-lock.json file is specified The default is to only scan the specified package-lock.json file and omit dev dependencies When using the npm type and a package-lock.json file is not specified The default configuration should be to omit dev dependencies and scan the node_modules directory Each of these options would have an optional parameter to include the dev dependencies (--include-dev) Each of these options would have an optional parameter to ignore pacakge-lock.json files found under node_modules (--package-lock-only ) This has been implemented in pgscan 1.5.6 which I will be pushing shortly, and these options will be added to BuildMaster 2023.2. Thanks, Rich

@gdivis Thank you

Hi @k_2363, We cannot get the endpoint ApiKeys_CreateOrUpdateApiKey to get to work. It seems that the JSON requires ApiKeyTasks_Table (IEnumerable1)`. Unfortunately we cannot find what we have to provide here. If i look at the Stored Procedure, it seems that this cannot be filled with an API request. Hmm, it looks like you may not be able to use table-value parameters via JSON. I don't know how easy that will be to add support for; one option is just to just do direct INSERT statements into ApiKeys and ApiKeyTasks tables. I'm aware of at least one other user that does that, since it was significantly easier to do a single statement that joined on another table in another database on the same SQL Server. It's not ideal, but this is pretty rare use case. Would that work? Thanks, Steve

Hi @Dan_Woolf , Thank you for your message. We've updated to the most recent version from 2023.16 to 2023.18 and I can confirm that this is now working! Thanks!

Hi @Evan_Mulawski_8840 , That particular bug may be resolved by running the patch script attached to this upcoming change: https://inedo.myjetbrains.com/youtrack/issue/PG-2484 As for retrying the migration; there will be a button on the ProGet root page if there is a failed/incomplete migration (/) that allows you to retry it. This will open to the /retry-migration URL, which I would recommend using instead of a database insert. Best, Dean

Hi @w-repinski_1472 , Based on your initial usage, I think SQL Server Express will suffice. The ProGet database is basically a package metadata index, and essentially stores things like package name, version number, and a variety of things including the manifest file (.nuspec, package.json, etc). It's maybe a few kb per package, and you'll need 100k's of packages to even reach 1GB of metadata storage. In your information you state that network connections are the bottleneck. I don't understand this completely in times when we have 100G cards, maybe I don't understand the scale on which ProGet is used in other companies. The issue is with the number of connections, and a single server struggling with 100's of expensive queries/requests per second. Running "nuget restore" or "npm restore" will hammer the repository with 1000's of simultaneous requests, and many of those need to go to nuget.org or npm.json to be resolved. When you have multiple users and multiple build servers running these kinds of restores, then you run into load issues. At about 50 users, a load-balanced / high-availability cluster starts to make sense. After 250 users, sticking to just a single server doesn't make a lot of sense (cost of downtime is expensive). Once you need a server cluster, then upgrading SQL Server would probably make sense. There's a big cost difference between a single server and a server cluster - in part the ProGet licensing fees, but also managing a server cluster is more complicated. Some organizations prefer to start with high-availability right away rather than worry about upgrading later. See How to Prevent Server Overload in ProGet to learn more. hope that helps clarify! Best, Steve

Hi @hashim-abu-gellban_3562, Due to some reasons I don't fully understand, authenticating to the Docker API requires using a Bearer authentication token Authorization: Bearer {token} Here is an example for how to get that token: function GetDockerToken() { param ( [string] $packageName = $(throw "-packageName is required. This is the namespace and image name. For example: library/my-container-image"), [string] $feed = $(throw "-feed is required"), [string] $actionToAuthorize = $(throw "-action is required. This is the docker action to be authorized (pull, push, delete, etc)"), [string] $apiKey = $(throw "-apiKey is required"), [string] $progetBaseUrl = $(throw "-progetBaseUrl is required. "), [string] $service ) if ($service -eq "") { # This expects that $progetBaseUrl is prepended with "https://" If you are using "http://" then change 8 to 7 below. $service = $progetBaseUrl.SubString(8,$progetBaseUrl.Length-8) } $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f "api","$apiKey"))) $response = Invoke-WebRequest -Uri "$progetBaseUrl/v2/_auth?service=$service&scope=repository`:$feed/$packageName`:$actionToAuthorize" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} if ($response.StatusDescription -eq "OK") { $token = ($response.Content | ConvertFrom-Json).token $token } } I know we plan to document all this better some day, for now you can find the Semantic Versioning for Containers page. Dean

Hi @Stephen-Schaff, Thanks for the detailed write-up; the behavior you describe makes sense, and made for very copy/pasting PG-2478 :) We anticipate getting this in the next maintenance release, scheduled for Sept 15 Best, Dean

Hi @cimen-eray1_6870 , Great questions; there's no problem having a second instance with ProGet Free Edition. The relevant restriction is that you can't use a Connector in ProGet Free Edition to connect to another instance of ProGet (either another Free Edition or your paid edition). Hopefully you can use your Maven feed as a proof of concept for implementing it in the main instance. Good luck! Cheers, Steve

Hi @gdivis Thanks for the update I moved to docker recently - much more flexible than Microsoft

@atripp Good to know Thanks