@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

Thanks for the fast answer. I will tell my people to reduce the varable length

Assuming that ProGet has access to inedo.com, ProGet will automatically activate. Otherwise, you will have to manually activate. Activation is required when the CPUID changes or the MAC address changes. So, the easiest thing to do is just to ensure those don't change; these are almost certainly options in the VM Host. It's possible to programmatically active, but quite bothersome. You'd need to call our (undocumented) product registration endpoint, then add data to the ProGet database, then reset the web application. We don't really support this, and it's quite fragile (i.e. having someone else maintain this as a SOP), so it's best to just ensure the ProGet VM doesn't change and require re-activation.

Hi Chris, You'll need to run the NuGetPackagesV2_SetListed method instead. In order to this, you'll need to mark it as non-internal; this can be done with a simple database query... UPDATE [__StoredProcInfo] SET [Internal_Indicator] = 'N' WHERE [StoredProc_Name] = 'NuGetPackagesV2_SetListed' This will be also be updated in 5.2.10 as PG-1549.

We recently moved our documentation; do you know where you found those 404s? We're also monitoring via Analytics Tools as well, but finding sooner is better :) Anyways PSCall is good in Orchestration Plans (can be done in a Configuration Plan, under some conditions), and PSEnsure is best for Configuration Plans. Explaining Ensure vs Execute can be tricky, but I'd recommend checking out our ebook, called Windows-first Guide to Infrastructure as Code and Continuous Configuration Automation :)

We definitely want to add these as first-class Operations in our Windows extensions, but in the mean time the best route is to use the PSDsc Operation to invoke the Windows Feature DSC Resource PSDSC WindowsFeature ( Name: Web-Server, Ensure: present ); Hope that helps!

I think they mean that they want to be able to "recycle" the container, hence needing it to be abvle to have password changes.

Thanks, with version 2.2.5 all works fine.

Will help support a push command at some point? ;-) We documented a few ways you can Publish Helm Charts, because there was no push command at the time. It doesn't seem there's now one... https://helm.sh/docs/helm/