Config schema: Define AWS "provider" properties (top level only)

[medikoo]

Use case description

Part of #8022

Proposed solution

Define schemas for following properties:

Note: As that's a lot, proposed PR's may cover just some of them (or even just single one)

• stage
• region
• stackName
• profile
• logRetentionInDays
• deploymentBucket
• deploymentPrefix
• rolePermissionsBoundary
• cfnRole
• stackTags
• iamManagedPolicies
• iamRoleStatements
• stackPolicy
• notificationArns
• stackParameters
• rollbackConfiguration
• tags
• logs.frameworkLambda

Configuration should be done directly in: lib/plugins/aws/provider/awsProvider.js:

serverless/lib/plugins/aws/provider/awsProvider.js

Lines 141 to 142 in d403d9c

	// TODO: Complete schema, see https://github.com/serverless/serverless/issues/8016
	serverless.configSchemaHandler.defineProvider('aws', {

[glb]

@medikoo I'd like to take a crack at resourcePolicy to address #7795 ... any pointers on how to write tests for this?

I am able to get an error when I run manually:

Serverless: Configuration error at 'provider.resourcePolicy': should be array

🎉 but I'm trying to figure out the right magic to add a unit test to validate the validation. If I'm lucky you will see this before I pour too much more time into figuring out all the wrong ways to do it. 🙂

I have looked at the tests in #7335 but haven't figured out how to write a new one that tests the right thing.

UPDATE: I think I've figured it out ... had to use

runServerless({
  config: invalidOptions,
  cliArgs: ['print'],
})...

instead of

runServerless({
  config: invalidOptions,
  cliArgs: ['info'],
})...

as info was getting into all kinds of unhelpful things. I had used info originally because the tests in #7335 did that (unnecessarily?).

UPDATE 2: Nope, print doesn't validate. info does.

UPDATE 3: Got it by using awsRequestStubMap to stub out CloudFormation.describeStacks and CloudFormation.listStackResources.

[medikoo]

@glb great to hear that!

any pointers on how to write tests for this?

I'm not sure if we should write tests for schema. AJV (validation engine) is extensively tested on it's own, so e.g. testing that adding field to required array, will make it required feels unnecessary and quite costly from maintenance perspective.

I believe we should just test a valid configuration (that'll confirm that by accident we do not invalidate a valid format), and it's ok to invalid cases purely in scope of schema rules (without further tests).

We may eventually write a single tests, that confirms on bad format in all properties and that unwanted properties are not sneaked, and if we do that, I will set configValidationMode: error for runServerless run, so intended action is pursued and there's just validation error that we deal with