Initial support for vsts-cli #581
Conversation
|
Neat! It's not obvious why builds are failing; do they pass on your machine? |
|
They did. I liked the fact that you had Pester there (I should make more use of it elsewhere!) |
|
Hmm.. tests definitely failing on those builds though. I'll see if I can reproduce the problem locally. Is there any tricks to testing posh-git? |
|
For some reason, on the CI builds, the $result is empty for my new tests, but not having any success replicating that locally |
|
Looks like it's related to the alias that vsts-cli creates for git. Will need to mock something for the tests.. |
- Add all pr commands and short commands - Add test for filtering params Implements dahlbyk#549 Not implemented in this PR: 'subgroups' (work-items set-vote policies)
The idea "known alias" is that we can standardize handling of a
particular alias command (e.g. 'git pr' pass-through to 'vsts code pr')
without hooking on the alias name. For example, 'pr' could reasonably be
used to manage GitHub, so this allows us to avoid using vsts tab
expansion in that case.
Namespacing the alias ('vsts.pr') prevents conflicts with a real alias.
There was a problem hiding this comment.
In retrospect I probably should have PR'd into your PR, since this is more of a proposal than a fix, but too late for that.
Anyway, as I noted in the commit I'm trying out the idea of shifting this to a "known alias":
The idea "known alias" is that we can standardize handling of a
particular alias command (e.g. 'git pr' pass-through to 'vsts code pr')
without hooking on the alias name. For example, 'pr' could reasonably be
used to manage GitHub, so this allows us to avoid using vsts tab
expansion in that case.Namespacing the alias ('vsts.pr') prevents conflicts with a real alias.
Rather than matching what the VSTS pr alias expands into, the "known alias" idea allows us to swap in a "command" that posh-git knows how to match whenever it recognizes the alias value. To prove the point, I've shifted the tests to not actually depend on a pr alias, just an alias that acts like it. Thoughts?
More generally, I'm not thrilled with the hoops you've had to jump through to get sub-command expansion working. I believe git flow is the only other place we're doing subcommand expansion, but without parameters. I'd love to be able to do something like $longGitParams['vsts.pr'] = $longVstsParams and have all the subcommands work as expected without our remaining vsts.pr-specific matches. But we don't have to do that here before merging, just dreaming.
|
Totally fine with your changes 😃 I tried to fit in with the existing structure and make the smallest change possible to get the subcommands working as I could. Making a more general solution totally makes sense. I'd guess the design for that could start to become evident once there's one or two more extensions that want to be included. One of the areas I skipped for this PR was the vsts 'subgroup' commands, which I think end up a bit like sub-sub-sub commands. Another thing for the future is to add value completion for the boolean and 'enum' type parameters. But baby steps - get something basic working and then I can build on that! |
It's an interesting design process, for sure. I'd almost argue that posh-git isn't even the right place to solve this problem for Out of curiosity, is there any overlap between data available from
💯 I'm going to give this a day or two to see if @rkeithhill or anyone else weighs in. |
src/GitTabExpansion.ps1
Outdated
| @@ -264,6 +276,23 @@ function GitTabExpansionInternal($lastBlock, $GitStatus = $null) { | |||
|
|
|||
| switch -regex ($lastBlock -replace "^$(Get-AliasPattern git) ","") { | |||
|
|
|||
| # Handles git pr alias | |||
There was a problem hiding this comment.
It's not a big perf hit but it strikes me that these "case" statements are less likely to be encountered than the basic git <cmd> completions. As such, it seems like the new vsts-oriented "case" statements should go towards the bottom after the more common cases.
There was a problem hiding this comment.
Other than the above, this PR LGTM.
I'm not sure. git-tfs is a bridge like git-svn. I used it a few years back against an on-prem TFS server. It doesn't have the concept of pull requests, so I don't think there's much in common. It seems the focus of vsts-cli is git operations rather than TFVC. |
- Following @rkeithhill's suggestion
|
Thanks! |
1 similar comment
|
Thanks! |
prcommands and short commands (equivalent tovsts code pr)Implements #549
Not implemented in this pull request (future work):
vsts codeoperations (eg.repo)