Fixes #48

[zleight1]

Added support for configured canned ACL on S3 put call.
Added to readme with new parameter.
Added to s3 gitlab example.

[frehner]

code looks good, just have a question about DO situations

[zleight1]

There’s already a call to check if it’s DO so we could leverage that. The problem with the ACLs is that the response I was getting from the api was super unhelpful, so I would lean more towards the side of having the checks against the valid values. Maybe it could throw an error if the value isn’t valid for either S3 or DO so it would be easy to see in the logs?

…

On Thu, 21 May 2020 at 18:11 Anthony Frehner ***@***.***> wrote: ***@***.**** commented on this pull request. code looks good, just have a question about DO situations ------------------------------ In src/io-methods/s3.js <#49 (comment)> : > @@ -21,6 +21,17 @@ function parseFilePath(filePath) { }; } +const validCannedACLs = [ + // See: https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl + "private", "public-read", "public-read-write", "aws-exec-read", "authenticated-read", + "bucket-owner-read", "bucket-owner-full-control", "log-delivery-write" according to https://developers.digitalocean.com/documentation/spaces/ only private and public-read are available for DO what should we do in that case? should we be checking to see if they're using DO and then validate against that set of options? or should we remove the validation altogether so that we don't have to ensure we're always up-to-date with 2 external services? thoughts? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#49 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEJBWKVIXFKETOKABZD2OTRSVACBANCNFSM4NGVWBGQ> .

[frehner]

yeah I'm good if we just utilize that DO check.

[joeldenning]

it could be nice to support any of the S3 PutObject params, instead of just the ACL. See my suggestion at #48 (comment) for what a config file could look like for this.

Additionally, another thing to consider is whether to support a different ACL per import-map-deployer location. I'm okay with skipping that for now since it makes things more complicated, but thought I'd bring it up.

[zleight1]

I'll go ahead and make the changes to support any of the s3 parameters. I'll remove the validation that I originally wrote, and just pass along whatever we get from that s3 putObject config. This way we don't need to change code if the values/structure of the putObject changes, and any DO changes would just be in the config.

[joeldenning]

Looks good to me - thanks!