Feature request: Adding and removing Agent pools (and agents)

[rwaal]

I would be very convenient if the module could add and remove agent pools, using commands like New-ADOAgentPool and Remove-ADOAgentPool.

Similarly, it would be very helpful to be able to remove agents from a pool. For example, when a self-hosted agent VM has been decommissioned. A command for that could be Remove-ADOAgent.

Of course I don't expect you to just implement this. Everyone has a very busy schedule. It's just an idea for some new features that would certainly be useful for me. In any way, thanks and keep on doing the good work 😄

[StartAutomating]

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.

[rwaal]

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.

[StartAutomating]

@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.

[rwaal]

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

[StartAutomating]

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