-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(aws-s3-deployment): fix server side encryption parameters #6006
Conversation
In https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#step-4-commit
|
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @mattsains, PR looks good!
I do have a small note though. Like you pointed out, you changed the key names to match the aws s3 sync
command line options as specified here: https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html
Looking at the code, I see we actually have additional keys that don't match the CLI options:
- website-redirect-location should be website-redirect
- sse-customer-algorithm should be sse-c-copy-source
How do you feel about piggy backing this PR and issue to also fix those keys?
@@ -239,7 +239,8 @@ export = { | |||
contentLanguage: "en", | |||
storageClass: s3deploy.StorageClass.INTELLIGENT_TIERING, | |||
contentDisposition: "inline", | |||
serverSideEncryption: s3deploy.ServerSideEncryption.AES_256, | |||
serverSideEncryption: s3deploy.ServerSideEncryption.AWS_KMS, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of removes our test for the AES_256
use-case, which we don't want to give up (correct me if i'm missing something here).
Lets just add another test for the AWS_KMS
case. Which I see is completely missing from this file.
In general, we always prefer adding tests, rather than extending or changing existing ones. Even if it means duplicating most of the test code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your philosophy might vary, but this is just checking that the code correctly translates the property keys. The actual values of these properties doesn't have any factor on the test. I just changed this to AWS_KMS so I could add an additional property to the assertion. I could have left it as AES_256 and although it doesn't really make sense to specify a KMS key ID along with AES_256, the test would still pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing to consider is what use case this test is testing: "object metadata can be given" - I haven't eroded this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your right, I didn't notice which exact test this was in. This test simply validates the given metadata: { "A": "1", "b": "2" }
is translated into { 'x-amzn-meta-a': '1', 'x-amzn-meta-b': '2' }
.
This means your added properties don't belong there (in fact none of the additional properties belong there).
What I would expect to see is an another test, perhaps call it 'props translate to system metadata', that validates the properties are translated to the expected keys. This test can than porbably be modified every time we add a property. Its important also not to mix test-cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, I don't understand this piece of feedback. It seems like you're asserting that this case is testing the metadata -> UserMetadata mapping. However, there are far more fields in this test for everything else -> SystemMetadata in this test.
Anyway, I'll copy this test case to another test case and remove most of the fields from the original test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I just realized the props translate to system metadata
test im suggesting is in fact just a subset of the object metadata can be given
test. Its just confusing because metadata
is the name of property as well.
I'm still not liking the removal of that property value because in affect it does erode a test. Imagine for some reason we change this enum value, some test should fail. Currently, it looks like its this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, now the confusion if out of the way, hopefully.
What i would do is:
- Leave the current test as is.
- Add another test that simply validates translation of the missing keys. Why another test? because I do want to use the AWS_KMS value in the new one, but also leave the test for AES_256.
Or whatever combination that gets us to a point we are validating both enum values.
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a systemic problem with these tests. The following classes have values which are not tested:
- CacheControl
- StorageClass
For the purposes of getting this PR approved, I will add tests for the ServerSideEncryption enum
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this PR with that test.
@mattsains Wrote:
Regarding the checklist, here it is: https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#pull-request-checklist Regarding the team, your'e right, its probably outdated. I'll see that its fixed. Thanks. |
Will do |
@mattsains Wrote:
Not sure what you mean by "attach my local copy...". Have you checked out our integration tests section? https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#integration-tests? Also - probably more relevant to your use case, since you actually need to run Adding this test won't be a blocker for this PR, since i feel pretty confident about the fix and about our ability to maintain it. However, i'd still take a stab at getting a full integration test working as it will really help with future contributions, totally up to you :). I'm ready to help of course. |
While trying to fix the customer-algorithm property, I found another bug: #6080 I don't have time to fix that so I just created the above issue. |
Nice, thanks 👍 |
I updated my branch with the requested changes. |
Pull request has been modified.
@@ -239,7 +239,8 @@ export = { | |||
contentLanguage: "en", | |||
storageClass: s3deploy.StorageClass.INTELLIGENT_TIERING, | |||
contentDisposition: "inline", | |||
serverSideEncryption: s3deploy.ServerSideEncryption.AES_256, | |||
serverSideEncryption: s3deploy.ServerSideEncryption.AWS_KMS, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your right, I didn't notice which exact test this was in. This test simply validates the given metadata: { "A": "1", "b": "2" }
is translated into { 'x-amzn-meta-a': '1', 'x-amzn-meta-b': '2' }
.
This means your added properties don't belong there (in fact none of the additional properties belong there).
What I would expect to see is an another test, perhaps call it 'props translate to system metadata', that validates the properties are translated to the expected keys. This test can than porbably be modified every time we add a property. Its important also not to mix test-cases.
Pull request has been modified.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Pull request has been modified.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request is now being automatically merged. |
fixes #6002
I wasn't able to attach my local copy of the CDK to a package using one to perform an integration test, but I am happy to accept assistance doing this.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license