github
Re-Design CLI to be multiple gh extensions
The customer acquisition and upgrade experience for gh gei is better than ado2gh because it uses the gh CLI to handle installation and upgrades. As we introduce new migration scenarios like BBS and GitLab in the future we want to have a consistent pattern we can use here.
We're going to make ado2gh into it's own gh CLI extension (gh ado2gh), and follow the same approach for the upcoming BBS migration capabilities (gh bbs2gh).
As part of this work we're going to make the investment to reduce code duplication between the commands in ado2gh and gh gei. We'll do this by moving shared commands into the Octoshift project and come up with an approach to override things in each separate CLI extension project (e.g. to change arg names if necessary).
Tasks
- [ ] #515
- [x] #507
- [ ] #497
- [x] #498
- [ ] #499
- [ ] #500
- [ ] #501
- [ ] #502
- [x] #503
- [ ] #504
- [ ] #516
- [ ] #517
