@apxltd Thanks for the info ! I missed this one in the documentation :/ I've disabled the caching and it works fine now

Actually, I'm not wrong; ProGet is simply not designed for your use case. It is infinitely more stable in the use cases it was designed for. ProGet also can't bake you muffins; an "oven" is much more suited for this purpose. There are lots of tools that solve different problems, and ProGet is not designed as a desktop-based, single-user "server" for personal use. We have no intention of building such a tool; our tools are designed for teams to work together, not power tools for single users. Anyways, it looks like found the tool that you're looking for. Best of luck.

Hi As I was building a test case, I found an error in my code After correction, It is working as expected. Sorry !

Yes; you would use a Docker feed and a Connector for this. ProGet will cache the container images and metadata, so it should give you better reliability when Azure container services has an outage or they introduce a new "feature" that breaks things ;)

Get in touch direct,happy to work toether on POC/implementation

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.

Of course, plan versioning is introduced in a later version, and Rafts (which allow for Git-based storage) is coming in 6.2. I definitely understand the hesitance to upgrade, but worth noting ---- for once 6.2 comes around we'll offer some great migration tactics to let you pull applications from really old versions of BuildMaster. We'll also better support multi-instances of BuildMaster, so each group can upgrade as they'd like. That said, the Plans database table will contain your OtterScript plans. Not sure if that's a good solution, but pulling from that table will give you latest versions.

I think by default all you need is to set the host to "localhost" and the port to "8888". If that doesn't work, check the Tools > Options > Connections tab within Fiddler for the port number.

@apxltd Yes it is, thanks for you fast response... I will try to use these commands you just wrote...

Hi @ReginaldD, did you manage to bulk-delete packages from your server using inedo API? Cheers,

Pb solved: remove InedoCore 1.5.1 Restart BuildMaster Install InedoCore 1.5.0 The Execution Dispatcher still stuck (even after 5 mn) Reboot VM Pb gone

Hi Philipe, Thanks for the report, I've added an issue to fix this: https://inedo.myjetbrains.com/youtrack/issue/OT-345 It should be included in Friday's release, but it may get delayed to next week because there aren't any other issues scheduled for it yet :) Thanks, -John

ProGet does not support the deprecate command, but you could accomplish the same thing by adding a Manual Vulnerability. We can't seem to figure out what the deprecate command actually does, or how it's supposed to work. It's pretty poorly documented, and since there is no deprecated flag in npm package metadata, the client must be doing some strange things to check. Who knows... Anyways, I'd stick with Manual Vulnerability, since at least that's documented a lot better and won't change from client version to client version.

The Execution Dispatcher (Admin > Manage Service) doesn't start immediately after service restart; this causes the same symptoms you're seeing now. You can manually trigger it on that page, or just wait. It's a known issue, and just a (temporary) workaround to problem where executions start in the middle of agent upgrades. We've addressed it in Otter, but it's a bit complex to do in BuildMaster pre-6.2.

I ran the full install again and realized it was the cached images in Chrome causing the issue. IE was fine, so I knew immediately it was Chrome. Thank you again!

The homepage will attempt to connect to inedo.com to download latest news, and it will also connect to the database to provide a summary of feeds (dashboard). However, if either of those operations times out, then you should get a prompt error. Maybe, for some reason, the request isn't even being routed to ProGet. You can connect ProGet to a proxy like Fiddler (Admin > Proxy), and then attach to SQL Server to see if anything is timing out..

I took a while to get back to this thread, but here goes: Today we upgraded to the MSSQL backed version of ProGet, that is currently on the Docker hub (5.2.9.11), and most of it went smooth. However, when restoring all the packages, I did get the unresponsive errors again. But this time the server came back and we could see the log messages. After changing the connection string, things seem to be more stable now when doing a full restore. The new connection string has this appended to it: "Max Pool Size=200;" Hopefully this version keeps us happier, as the old version needs a reboot every other day.

Thanks a lot, I confirm it's working now with v5.2.9