Thanks for the detailed information, that's very interesting and a great assessment. We wouldn't have found this using all of these variables, especially the different Windows desktop version I suspect this might be a bug in the underlying libraries? We just use an HttpListener and a HttpWorkerRequest, both which should handle all of this, in the simplest way possible. I'll ask around and see if anyone knows. But I guess, at least you found a work-around which I'm glad to hear!

Your best bet would be to use the helm api endpoint; we don't document how third party apis work (it's hard enough to document our own!), but you could use a tool like fiddler to see what the helm client uses.

I know it's a little late. I had the same problem today and solved it by installing Microsoft Sysinternals SubInCal (https://www.microsoft.com/en-us/download/details.aspx?id=23510). Set the permissions with: cd "C:\Program Files (x86)\Windows Resource Kits\Tools\)" subinacl.exe /service INEDOBMSVC /grant=domain\user=PTOS

Thanks for this post id did help me a lot. I did also get the message "Specified from feed '' does not exist." while trying package promotion. This message is missleading as the real issue was the http Client not passing all the content types as the server wanted. I did try with postman and powershell Invoke-WebRequest. Think the server is unecessary strict with handling the requests, but maybe there is a reason for that. Please consider adding a few "HttpClient" example to the documentation in different languages like powershell, java,c#. It would save the customer a lot of time. https://docs.inedo.com/docs/proget/reference/api/package-promotion

@atripp Thanks for the reply. I submitted a Pull Request myself to the dependabot-core repo.

Hello; What are you trying to do? This definitely won't work for several reasons. Ensure-File is an "Ensure" operation and will detect configuration drift and can optionally create the file if it doesn't exist; but in this case, it would be a 0-byte file named test.zip, which isn't a valid zip Extract-ZipFile is a "Execute-only" operation, which means it will run only within a block (e.g. { ... } ) if drift was detected (i.e. the file didn't exist in the operation before); but if that was the case, it would fail because it's not a valid zip file You probably want to use an Orchestration plan for this. Please read through this eBook to get feeling for how configuration and Orchestration Plans: https://inedo.com/support/resources/ebooks/windows-first-iac-cca

Thank you. We have upgraded and now it works. For clarity any REST API call would not work before the upgrade.

@James-McAllister_0459 said in deleting docker images via REST API: Is there any way to get the published date or created date of the image from a REST api? The Docker API in ProGet doesn't (currently) return a Last-Modified header, but depending on which date you want, it can still be accessed: Published date can be accessed via the native API using the tables you identified. However, this API is generated directly from internal ProGet database procedures, so this may break in the (unlikely) event that ProGet's Docker database structure changes. Created date is a property of the image, which is embedded in the manifest's config field. Inside the JSON blob referenced by the manifest, the creation date of the image is in a field named created. This is optional in the Docker specification, but if you're building your own images, it should always be present.

Yes, it solved the issue. thank you.

@gdivis said in ProGet 5.2.13 breaks Symbol Server / PDB download: It looks like this was caused by a change in our internal deployment process. I've logged this as PG-1615, and it will be fixed in ProGet 5.2.14, which is scheduled for release on Friday (October 18). Thanks for the report! Thank you very much for the quick fix!

@gdivis Awesome! Thanks!

Okay thanks for the fast answer

Hi; that message is coming from the operating system and ProGet does not have any sort of limit (we have customers with terrabytes of packages); perhaps you've configured it to a different drive, or something. I'd check there :)

Hello; for this, or really any other Dockerized web application, you can setup a reverse proxy. There are a ton of ways to do this, but I'd suggest to search for "How to Configure a Nginx as a HTTPS Reverse Proxy" and see which option(s) make sense for your environment

This would be captured in an event (Admin > ProGet Event Log); the UI doesn't currently support package-level queries (you can filter a few other ways), but you could do a database query pretty easily... SELECT * FROM [EventOccurrences] WHERE [Event_Code] = 'PKGADD' AND [Feed_Id] = 2 AND [Details_Xml].value('(/Details/@Package_Name)[1]', 'varchar(max)') LIKE 'Carbon' AND [Details_Xml].value('(/Details/@Package_Version)[1]', 'varchar(max)') LIKE '2.9.0'

No problem! That worked. Thanks.

I'll start with the easy one; connectors are "read only", there is no mechanism to push a package to a connector in ProGet. As for authentication, I really don't know. That's weird, and it's definitely nothing in ProGet. The 401 could be coming from a proxy server (inside your network) or from registry.npmjs.org itself, and there's no way to know within ProGet which it is. I can't imagine it's a proxy server that somehow works with a npmjs.org username/password. But, maybe it is. I don't know why registry.nmpjs.org would send you a 401. Other users haven't experienced this, and I just tested it on a brand new instance myself... and the connector worked just fine. There is talk of throttling large organizations, so maybe it's related to them blocking your IP or something? It could have also just been a temporary glitch, somewere. Maybe if you remove authentication, it will work. ABout the only way to diagnose this would be to attach ProGet to a tool like Fiddler or WireShark, so you can see the requests PRoGet makes, then reproduce those exact same requests, and either reach out to your internal IT folks or try your luck with npmjs.

Hello; Your best metric is going to be your users; if they're complaining it's slow, then it's probably too slow. My guess is that it's intermittant (during peak times). But in any case, it's not about the number of packages (a micro server can easily serve millions of packages nearly instantly), it's about the number of simultaneous connections (requests) to the server, and the features you've enabled (like license checking, etc). It sounds like you've got a single "2 core instance with 8gb of ram" server; while you can try to increase the hardware, the bottleneck is most likely network related; a single server might not just be enough to keep up with the traffic from your developers. Keep in mind that "plain old NPM" (i.e. registry.npmjs.org) runs on a massive, dedicated data center and is heavily cached (basically read-only). The ProGet Free to ProGet Enterprise article contains some general guidance that might help answer your questions: High Performance: 1 Server per 50 Developers. The network never slows down, never crashes. Average Performance: 1 Server per 100 Developers. The network slows down and drops productivity 10% on average during peak times daily. Acceptable Performance: 1 Server per 200 Developers. The network slows down and drops productivity 10-30% during peak times daily. Unacceptable Performance: 1 Server per 250+ Developers. The network is unstable and crashes. You can try disabling connectors, disabling license checking, disabling vulnerability scanning -- but those are really important features, so your best bet will be to plan for a load-balanced scenario. See How to Prevent Server Overload in ProGet to learn more.

Hello Thank you for the tips Cdt

Hello; this is the first such request for GCP. These are extensible components, and it's possible we can support it very easily -- but we like to partner with customers, since we have very little knowledge about GCP and like to make sure it works in the field before making it public. The best way to get this rolling would be to submit a feature request, and ideally bring it up with your technical account manager to see if it can get escalated.