feat(cli): --yes option to accept all questions

[ren-yamanashi]

Adds a new --yes cli option so that when provided, commands can continue without confirmation. Any confirmation prompts will be accepted. Other user input will use a default value if available. The CLI might still prompt for input in situations where there is no default answer.

Fixes #732

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.80%. Comparing base (779352d) to head (2acab46).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #826      +/-   ##
==========================================
- Coverage   83.91%   83.80%   -0.11%     
==========================================
  Files          71       71              
  Lines       10401    10431      +30     
  Branches     1326     1329       +3     
==========================================
+ Hits         8728     8742      +14     
- Misses       1632     1650      +18     
+ Partials       41       39       -2     

Flag	Coverage Δ
suite.unit	83.80% <100.00%> (-0.11%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ren-yamanashi]

Q. It should return msg.defaultResponse instead of true?

[mrgrain]

Yes, we need to return true for isConfirmationPrompt, msg.defaultResponse if there is one, and continue otherwise.

I would also like us to still print the question and answer and indicating that --yes was used.

We should also only do this after the this.skipApprovalStep(msg) check. On the other hand, --yes should make scenarios work where we don't have a TTY or are using concurrency. So we will need to restructure the checks.

[mrgrain]

Two existing uses of promptly that should be changed over as well as part of this:

aws-cdk-cli/packages/aws-cdk/lib/cli/cdk-toolkit.ts

Line 980 in 5bb90cb

const confirmed = await promptly.confirm(

aws-cdk-cli/packages/aws-cdk/lib/cli/cdk-toolkit.ts

Line 2121 in 5bb90cb

const confirmed = await promptly.confirm(`${chalk.cyan(question)} (y/n)?`);

Refactor should be a confirm:

aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/toolkit/toolkit.ts

Lines 1193 to 1196 in 5bb90cb

	const response = await ioHelper.requestResponse(IO.CDK_TOOLKIT_I8910.req(question, {
	responseDescription: '[Y]es/[n]o',
	}, 'y'));
	return ['y', 'yes'].includes(response.toLowerCase());

[mrgrain]

Yes, we need to return true for isConfirmationPrompt, msg.defaultResponse if there is one, and continue otherwise.

I would also like us to still print the question and answer and indicating that --yes was used.

We should also only do this after the this.skipApprovalStep(msg) check. On the other hand, --yes should make scenarios work where we don't have a TTY or are using concurrency. So we will need to restructure the checks.

[mrgrain]

Two existing uses of promptly that should be changed over as well as part of this:

aws-cdk-cli/packages/aws-cdk/lib/cli/cdk-toolkit.ts

Line 980 in 5bb90cb

const confirmed = await promptly.confirm(

aws-cdk-cli/packages/aws-cdk/lib/cli/cdk-toolkit.ts

Line 2121 in 5bb90cb

const confirmed = await promptly.confirm(`${chalk.cyan(question)} (y/n)?`);

Refactor should be a confirm:

aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/toolkit/toolkit.ts

Lines 1193 to 1196 in 5bb90cb

	const response = await ioHelper.requestResponse(IO.CDK_TOOLKIT_I8910.req(question, {
	responseDescription: '[Y]es/[n]o',
	}, 'y'));
	return ['y', 'yes'].includes(response.toLowerCase());

I went ahead and made these unrelated changes in: #904