s3 event schema#8330
Conversation
Codecov Report
@@ Coverage Diff @@
## master #8330 +/- ##
==========================================
- Coverage 88.01% 88.01% -0.01%
==========================================
Files 249 249
Lines 9307 9306 -1
==========================================
- Hits 8192 8191 -1
Misses 1115 1115
Continue to review full report at Codecov.
|
medikoo
left a comment
There was a problem hiding this comment.
Thank you @thewizarodofoz ! It looks promising. Please see my comments.
Also (I forgot to initially note in dedicated issue, sorry for that). We need to also define s3 block at provider section. It supports name, and all this properties:
serverless/lib/plugins/aws/package/compile/events/s3/index.js
Lines 19 to 36 in fc34140
@medikoo do you mean you would like to see a full fledged schema of all the bucket properties? Or just a validation for the allowed properties? |
I think it's similar case to CloudFront, where we take CF template properties one by one. So I would do same as there. So introduce proper schema for each property |
Codecov Report
@@ Coverage Diff @@
## master #8330 +/- ##
==========================================
- Coverage 87.39% 87.36% -0.04%
==========================================
Files 254 255 +1
Lines 9476 9461 -15
==========================================
- Hits 8282 8266 -16
- Misses 1194 1195 +1
Continue to review full report at Codecov.
|
medikoo
left a comment
There was a problem hiding this comment.
@thewizarodofoz Thank you! That looks very promising. Still I believe we should maintain convention with which other schemas are configured. Please see my comment.
If convention can be improved, I would first discuss and eventually refactor with other PR already existing schemas into new convention before adapting to new one in this PR
| serverless.setProvider('aws', new AwsProvider(serverless)); | ||
| awsCompileS3Events = new AwsCompileS3Events(serverless); | ||
| awsCompileS3Events.serverless.service.service = 'new-service'; | ||
| // TODO: remove awsS3BucketName.pattern stub when tests are refactored to use runServerless |
There was a problem hiding this comment.
We can remove this comment, as converting to runServerless means not writing this stub at all (a kind of test where AwsCompileS3Events instance is created individually)
| }, | ||
| additionalProperties: false, | ||
| }, | ||
| s3: require('./lib/s3/Bucket'), |
There was a problem hiding this comment.
Moving this out, breaks the convention. All others properties are defined inline, and this one is not, why exactly?
If there's no specific reason, I would keep it inline with other schema.
It's also way easier for inspection, which can be common when users may want to investigate why they receive the schema errors
There was a problem hiding this comment.
I will move the top bucket schema inline.
How do you feel about all other sub-schemas in seperate files and required by ./lib/s3/Bucket.js?
There was a problem hiding this comment.
I think all of them should be inline (or are they reusable across different places?)
Eventually all could be in one external s3.js file, but with that I would also move few other big blocks into separate external files (eg. definitions, functions, layers, resources`) - and that will be better to first handle in separate PR
There was a problem hiding this comment.
There is quite a lot of reuse of sub schemas. So having it all inline will require repetition.
I vote for moving all s3 related schemas into a single s3.js file which will be required by awsProvider.js and externalise other big blocks in a later PR.
There was a problem hiding this comment.
There is quite a lot of reuse of sub schemas. So having it all inline will require repetition.
In such case we may reference them in local env vars (we already do that in some places)
I vote for moving all s3 related schemas into a single s3.js file which will be required by awsProvider.js and externalise other big blocks in a later PR.
I'm fine with that, still let's put it in lib/plugins/aws/package/compile/events/s3/configSchema.js (the only file, with reusable parts organized via local vars)
There was a problem hiding this comment.
Thanks @thewizarodofoz for update ! Still, I've just noticed that as configured, schema intended for provider.s3 is not really attached.
It'll be nice to confirm that it works testing it against some invalid s3 event configuration
Also can you double check that s3 integration tests pass (see instructions: https://github.com/serverless/serverless/tree/master/test#aws-integration-tests ), e.g. when adding schema for provider.apiGateway we've introduced some bugs that got exposed by those tests (I've already fixed them with #8399 and #8400)
Thank you!
| }, | ||
| additionalProperties: false, | ||
| }, | ||
| s3: require('../package/compile/events/s3/configSchema'), |
There was a problem hiding this comment.
Here it's in effective, it needs to be in provider.properties group.
|
One more thing: In so far schemas I've converted most of Therefore I think it'll be nice to also adapt to it in context of this PR |
medikoo
left a comment
There was a problem hiding this comment.
Thank you @thewizarodofoz that's impressive!
I've spotted just few last issues. Also if I see correctly, it's the last missing schema (yay!).
Therefore I believe we also should remove this:
serverless/lib/classes/ConfigSchemaHandler/index.js
Lines 70 to 73 in bf356fd
relaxAwsProviderSchema method implementation)
| enum: ['DEEP_ARCHIVE', 'GLACIER', 'INTELLIGENT_TIERING', 'ONEZONE_IA', 'STANDARD_IA'], | ||
| }, | ||
| TransitionInDays: { | ||
| type: 'integer', |
There was a problem hiding this comment.
I think in such cases where natural number is expected, it'll be good to add minimum: 0
There was a problem hiding this comment.
ok.
the only place I left without min 0 is ReplicationRule.Priority because maybe one can de-prioritise a rule by setting a negative priority.
| type: 'array', | ||
| items: tagFilter, | ||
| }, | ||
| transition, |
There was a problem hiding this comment.
Let's remove that one, as it's deprecated (also it's casing is not right)
| AllowedHeaders: { | ||
| type: 'array', | ||
| items: { type: 'string' }, | ||
| }, | ||
| AllowedMethods: { | ||
| type: 'array', | ||
| items: { enum: ['GET', 'PUT', 'HEAD', 'POST', 'DELETE'] }, | ||
| }, | ||
| AllowedOrigins: { | ||
| type: 'array', | ||
| items: { type: 'string' }, | ||
| }, | ||
| ExposedHeaders: { | ||
| type: 'array', | ||
| items: { type: 'string' }, | ||
| }, | ||
| Id: { | ||
| type: 'string', | ||
| maxLength: 255, | ||
| }, | ||
| MaxAge: { | ||
| type: 'integer', | ||
| }, | ||
| }, | ||
| required: ['AllowedMethods', 'AllowedOrigins'], |
There was a problem hiding this comment.
|
@medikoo after removing |
@thewizarodofoz sorry for late response. It's errors in tests. I've fixed them in #8447, so now issue should be gone, |
|
Thanks @medikoo, unfortunately I don't think it solved it. |
@thewizarodofoz Indeed there was an error as we've taken modified I believe all should be fine now |
medikoo
left a comment
There was a problem hiding this comment.
Thank you @thewizarodofoz !
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #8330 +/- ##
==========================================
- Coverage 87.39% 87.36% -0.04%
==========================================
Files 254 255 +1
Lines 9476 9461 -15
==========================================
- Hits 8282 8266 -16
- Misses 1194 1195 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|

Closes: #8031