ado2gh expects a team name in URL

[renan-alm]

Description

After creating a repo in ADO, the repo URL looks like this https://dev.azure.com/<ADO_ORG>/_git/<ADO_REPO>.

However, ado2gh cli seems to expect the team name to be part of the repo URL, such as:
https://dev.azure.com/<ADO_ORG>/<ADO_TEAM>/_git/<ADO_REPO>

The URL returned in the error message (containing the team name) does not exist and the command fails with "source repository does not exist or you do not have permissions".

Unfortunately the cli forces the parameter --ado-team-project to be specified. Then even if I specify an empty string '', the result is still https://dev.azure.com/<ADO_ORG>//_git/<ADO_REPO> which is even more incorrect.

Reproduction Steps

Assuming you have admin on both ADO and GH, and PATs for both tools loaded on the env vars:

1. Create a git repo in ADO
2. Run: gh ado2gh migrate-repo --ado-org <ADO_ORG> --ado-repo <ADO_REPO> --github-org <GH_ORG> --github-repo <GH_REPO_NAME> --ado-team-project <ADO_TEAM_NAME>

Error msg:

[2024-09-06 13:39:20] [ERROR] Migration Failed. Migration ID: RM_kgDaACQ1NDk4NjJlOC04YzNhLTRjODgtODA2NS0yZjg2Zjg3N2NhNGQ
[2024-09-06 13:39:20] [INFO] Migration log available at  or by running `gh ado2gh download-logs --github-org target-org3 --github-repo adorepo2gh`
[2024-09-06 13:39:20] [ERROR] OctoshiftCLI.OctoshiftCliException: The source repository does not exist or you do not have permissions. Please ensure https://dev.azure.com/ado-org/renan-team/_git/new-ado-repo is the correct source url.
   at OctoshiftCLI.AdoToGithub.Commands.MigrateRepo.MigrateRepoCommandHandler.Handle(MigrateRepoCommandArgs args)
   at OctoshiftCLI.Extensions.CommandExtensions.RunHandler[TArgs,THandler](TArgs args, ServiceProvider sp, CommandBase`2 command)
   at OctoshiftCLI.Extensions.CommandExtensions.<>c__DisplayClass1_0`3.<<ConfigureCommand>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.AnonymousCommandHandler.InvokeAsync(InvocationContext )
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass17_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__5_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass8_0.<<UseExceptionHandler>b__0>d.MoveNext()

[renan-alm]

The confusion was sorted out with my colleagues.

In short, I was using the team name on the parameter "--ado-team-project". But this parameter is meant to have the ADO project instead. So it wasn't evident (to me).

Perhaps this bug can be converted to a refactoring removing the word "team" from the parameter.

[dylan-smith]

In ADO they used to be called "Team Projects". However, I just did a quick look and ADO seems to have changed how they refer to them at some point from "Team Projects" to just "Projects". So renaming our arg may be something we want to consider (but it would be a bit more work than a simple rename because it would be a breaking change).

[dylan-smith]

There is another backlog item that may have helped avoid confusion here also: #992