Feature request: Adding and removing Agent pools (and agents) about psdevops HOT 5 OPEN

Good deal. I'll update this issue again when I've added the command to create agents/pools/queues.

from psdevops.

0.4.5 (updated in PR #49) contains Remove-ADOAgentPool, which should remove pools, queues, and agents.

I'll be adding New-ADOAgentPool, which should create pools, queues, and agents, in a future build.

Please try out Remove-ADOAgentPool and let me know how it works for you.

Please provide any more information you can about your scenarios for managing agents, as this is an area of nearterm future development.

from psdevops.

Thank you @StartAutomating for working on this. It's very much appreciated!

I have one question though. When using the following command, I still get prompted with "are you sure you want to perform this action?"

Remove-ADOAgentPool -PoolID $myAgentPoolId -Confirm

I would have expected that the -Confirm parameter would ensure that the agent pool is removed without giving a prompt. I will be using the command non-interactively; in a pipeline or Azure Automation runbook. So the prompt will be a problem.

from psdevops.

@rwaal You can avoid the prompts by passing -Confirm:$false, an explanation of the general PowerShell behavior is below.

-WhatIf/-Confirm are actually very old PowerShell language features related to process confirmation.
If a Cmdlet SupportsShouldProcess, the Cmdlet automatically gets two parameters: -WhatIf and -Confirm
-WhatIf would preview execution but not run it. In most cases, this will print a message directly to the host. In PSDevOps, generally, it will return all of the parameters it would pass to Invoke-ADORestAPI, minus the PersonalAccessToken.

-Confirm seems a little counterintuitive, mainly because it's understood backwards and it's one of the very few times you'll often want to pass a $false to a [switch].

A Cmdlet that SupportsshouldProcess will prompt when $psCmdlet.ShouldProcess runs, if the the Cmdlet's ConfirmImpact -ge $ConfirmPreference (which defaults to 'High'). Lots of Cmdlets SupportShouldProcess but have a ConfirmImpact of Medium or Low (for instance, New-Item). So Passing -Confirm is actually saying always confirm, even if the confirm impact is low. Passing -Confirm:$false is saying never confirm, no matter what the cmdlet's ConfirmImpact is.

As a general rule, you'll find ConfirmImpact to be set to 'High' to commands you'd expect to have a high level of system impact, e.g. Remove-s, Install-s, Uninstall-s.

Almost every command in PSDevOps will act as describe above, as it is used to test aspects of REST apis without incurring cost, mocking, or using a secret value.

from psdevops.

Thanks for educating me on this. I've tried it with the -Confirm:$false parameter, and it works like a charm.

from psdevops.