Create setup and initial runtime checkers

[aemous]

Description of changes:

• Create code architecture for migration readiness feature.
• Implement ecr get-login breaking change checker.
• Implement default pager warning.
• Implement hidden aliases breaking change checker.
• Implement URL in params breaking change checker.
• Add new-change file.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[AndrewAsseily]

Looks like we have a couple of CI tests that need attention

[codecov-commenter]

Codecov Report

❌ Patch coverage is 58.62069% with 12 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (debug-migration@d6685a8). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
awscli/clidriver.py	36.84%	12 Missing ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##             debug-migration    #9703   +/-   ##
==================================================
  Coverage                   ?   93.27%           
==================================================
  Files                      ?      210           
  Lines                      ?    16833           
  Branches                   ?        0           
==================================================
  Hits                       ?    15701           
  Misses                     ?     1132           
  Partials                   ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ashovlin]

Thinking about it during review, --migrate-v2 feels a little too "action-y" like we're performing some sort of migration. What do folks think about --v2-debug or --migration-debug?

[ashovlin]

I'd rather not build up all of this state in classes and pollute clidriver.py like this. Could we treat it like to our existing logger.debug calls?

For this case, can we just move the printing to the call site

aws-cli/awscli/customizations/ecr.py

Lines 69 to 70 in 44f4c6f

	def _run_main(self, parsed_args, parsed_globals):
	ecr_client = create_client_from_parsed_globals(

with something like

def _run_main(self, parsed_args, parsed_globals): 
    if parsed_globals.migrate_v2:
       uni_print(...) # or maybe a migration_warning_print(...) if we wanted to centralize formatting
    ecr_client = create_client_from_parsed_globals( ...

That way we don't need to worry about printing later if an error happened once we passed the call site.

[ashovlin]

Thought might be tough if there are places we don't have access to parsed_globals.

[aemous]

To add a bit of context, the ecr get-login may be the only breaking change that occurs within a customization.

Here's the full list of breaking changes that depend only on the arguments entered to the CLI:

1. A blob type parameter starts with file:// (args only, globalargs.py)
2. A parameter starts with http:// or https:// (args only, globalargs.py)
3. ecr get-login replaced with ecr get-login-password (args only, you're proposing ecr customization)
4. Removed ~20 aliases (args only, globalargs.py)
5. Specifying pagination params via --cli-input-json (args only, globalargs.py)

4 of them are not tied to any specific customization and just exist on the level of args/values. Do you agree 1-3, and 5 make sense to implement in globalargs.py since all they depend on is the value of the args? I think its a good place because we're implementing a global arg, and we'd have access to all parsed args from this file.

Also, one breaking change doesn't depend on any information at all (all output will pass through default pager), we may also be able to lump that into globalargs.py. We may be able to lump others into globalargs, such as ones depending on env vars and configs. Are we good with implementing as many of these as we can in globalargs.py instead of clidriver.py, because I think that's what I'm leaning towards now.

And with this context in mind, would you still prefer 3 be implemented within the ecr customization? I feel globalargs.py may be a better place since it only depends on value of the args rather than anything specific to ecr such as ecr client creation, or the command implementation itself, etc., and it would be consistent with a lot of other checks, but still open to take more feedback on this, or any of the other breakages I listed.

[aemous]

Also, for the point on not building up state in a new migrationcheckers class, I can address that in next revision. Rather than the dictionary approach I'll just print from wherever we choose to implement the checks.

[aemous]

Also, for the point about printing later if an error happens, I think I was being overcautious there and we can likely remove the printing from within the exceptions. The only concern is if the error occurs before the migration checkers get printed. And if that occurs, the command won't run anyways, and the error is within somewhere else in CLI that would need to be addressed by the user or us, and would likely even occur in v2 anyways.

[ashovlin]

• Yeah, fine with shifting over to globalargs.py if that's where the majority of them will be - just didn't want to do that here in clidriver.py if possible.
• Not too worried about printing in the error mode, and like printing as we go.