Implement Set-ADOParameter about psdevops HOT 6 CLOSED

Pull Request #49 contained a pair of commands to try to address this concern:

• Connect-ADO
• Disconnect-ADO

Import-ADOProxy has been there for a bit, though you are correct in that it's a bit too fancy for most users.

Connect-ADO will currently default the -Organization on all -ADO* commands and it will also cache a PAT. It primarily works by setting $psDefaultParameterValues ( a PowerShell v4+ feature, if memory serves)

Disconnect-ADO will clear this information.

I'm going to leave this issue open so that you can validate and request additional changes. I'm probably going to have Connect-ADO augment tab completion on connection (so that -Project will autocomplete to the list of projects in your org you can see, for instance).

Please attempt use of this feature in 0.4.5, let me know if Connect-ADO fits your needs, and update this issue with additional feature requests.

from psdevops.

I 100% agree that typing in these fields every time is a PITA. I agree with the intent of the requirement. I've been thinking about how I'll accomplish such a thing.

There are a couple of things I have against just setting universal defaults:

1. Not all operations require -Project, and some act very differently when provided a project
2. It doesn't allow me do side-by-side operations (say, TFS --> Azure DevOps, or Org1-->Org2)

The other approach I've had in mind for this problem is the ability to create and maintain a "proxy module". In this, you'd do something similar to above, except you'd also specify the name of this module and an optional prefix.

So maybe something like:

Import-PSDevOps -Org Start-Automating -Project PSDevOps -Name StartAutomatingDevOps -Prefix SA 

That would import a copy of the module, which renames cmdlets to Get-SABuild, and defaults to -Organization StartAutomating and -Project PSDevOps

This way, you could have multiple proxies loaded, they wouldn't step on each other, and you could gracefully handle the "project cmdlets" or "org cmdlets" problem.

What do you think of this approach, compared to your suggestion?

Asking it another way:

Is it easier to remember to call your set first, and make a number of mandatory parameters optional (thus perpetually forget -Org or -Project) or is it easier to build your proxy once?

from psdevops.

Personally I could work with what ever improvement that you find is more aligned with your road map.

But from an adoption point of view, I'm afraid the proxy module will be to complex for what ordinary people are trying to gain. It is the first time that I ever heard about proxy modules, with a prefix, that will then prep my module context and variables. But I'm no powershell ninja, so I might just missing to learn about that concept.

For the side-by-side stuff, if you need these things, then you are in a more advanced scenario and know what you're after. Then you could do classic splatting to overcome this, and totally ditch our efforts and gain 100% control.

My scenario is more about being able to write a simpler and more lean script, that only works against a single organization and/or project.

To answer your question: I believe that it is easier for people to understand to run the Set-ADOParameter, than understading the proxy implementation.

from psdevops.

I'm going to assume that the rocket emoji means this issue can be closed. Please confirm.

from psdevops.

I'm going to test it tomorrow during my day job.

I'll keep you posted.

from psdevops.

I'm gonna call this "good" with Connect-ADO / Disconnect-ADO

from psdevops.