Config schema: Define AWS "httpApi" function event properties

[medikoo]

Use case description

It'll be nice to have httpApi event fully covered by schema validation

Proposed solution

1. Define schema for following properties at provider level (that's part of Config schema: Define AWS "provider" properties #8022)

• httpApi
• logs.httpApi

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', {

2. Define schema of all httpApi event properties

Should be done directly in: lib/plugins/aws/package/compile/events/httpApi/index.js:

serverless/lib/plugins/aws/package/compile/events/httpApi/index.js

Lines 51 to 54 in d403d9c

	// TODO: Complete schema, see https://github.com/serverless/serverless/issues/8021
	this.serverless.configSchemaHandler.defineFunctionEvent('aws', 'httpApi', {
	anyOf: [{ type: 'string' }, { type: 'object' }],
	});

[fredericbarthelet]

@medikoo I just realized I missed a particular scenario in my first PR : what happens if any of accepted string property within the configuration, both at provider and event level, is defined using cloudformation functions.

As an exemple, for httpApi provider configuration, the attribute id also accept an object with Fn::ImportValue key.

The use of CFN native function for string values is not httpApi specific. A reusable JSON schema ref would come in handy, WDYT ?

[medikoo]

@medikoo I just realized I missed a particular scenario in my first PR

Yes, I've also noticed that :) Actually a lot of got exposed after #8091 went in (you didn't have it yet in your PR, so it was silent for you). As it went already to master, I fixed that quickly with #8099

As an exemple, for httpApi provider configuration, the attribute id also accept an object with Fn::ImportValue key.

I've fixed it here: #8102 (this unfortunately is not covered by tests, I just happened to remind my myself about that, hence addressed with follow up PR)

Now config errors are exposed as crashes with tests, so it's unlikely we repeat merging incomplete schema (but that still depends on how good is tests coverage)