add support for passing an AWS.Credentials object

[line0]

This PR adds a credentials field to options.amazon which takes an AWS.Credentials object and assigns it to AWS.config.credentials.

I'm aware that gulp-elasticbeanstalk-deploy already supports accessKeyId and secretAccessKey, however these alone only work for permanent credentials. Adding support for AWS.Credentials should make this module work in pretty much all cases including AssumeRole accounts and federated users.

[coveralls]

Coverage increased (+0.02%) to 99.115% when pulling eeed453 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[Souler]

I like the idea of supporting any credentials system, it's not the first time a patch about that issue pops up in this repo. I think its worth reworking how we handle credentials now.

Looking at the credentials object seems like it would be a better solution to move accessKeyId and secretAccessKeyId that new credentials object.

Some examples of what I'm talking about:

How is used currently:

// ...
gulpEbDeploy({
  // ...
  amazon: {
    accessKeyId: "abcdefg", // optional
    secretAccessKey: "QWERTYASDFGH12345", // optional
    // ...
  },
})

How could be used after this patch:

Example 1

Same params as before, different object strcuture

gulpEbDeploy({
  // ...
  amazon: {
    credentials: {
      accessKeyId: "abcdefg", // optional
      secretAccessKey: "QWERTYASDFGH12345", // optional
    },
    // ...
  }
})

Example 2

Same params as before, AWS CLI credentials will be used

gulpEbDeploy({
  // ...
  amazon: {
    // No credentials object passed.
  }
})

Example 3

New Allow any kind of object strcture under credentials, AWS.Credentials constructor can fail, we should handle that case.

gulpEbDeploy({
  // ...
  amazon: {
    credentials: { /* .... */ },
    // ...
  },
})

Example 4

New Allow AWS.Credentials to be passed, we dont check for errors since it is already instanciated.

gulpEbDeploy({
  // ...
  amazon: {
    credentials: new AWS.Credentials({ /* .... */ }),
    // ...
  },
})

In order to keep this change a minor version and not a major, we should keep support for both approaches and maybe show a warning in case you are using the old system.

[Souler]

What I'm trying to say with the previous comment is, are you up to implementing something like that? If not i think I can revisit this on my weekend and give it a shot.

[line0]

@Souler Example 2 and 4 are already supported in this PR.
Changing the API to work like example 1 is easy enough. I actually considered adding this change to my initial PR, however i dropped it since it breaks compatibility with scripts using the current API.

Wrapping AWS.Credentials construction as laid out in example 3 actually adds complexity on both ends. First there's error handling/rethrowing as you already mentioned on the ebdeploy side and catching as well as handling the error on the integration side.
Then there's the issue of having to guess which descendant of the AWS.Credentials class the user actually wants (there's no shortage of them). I'm not convinced the tiny added convenience of not having to call the AWS.Credentials constructors is worth the hassle.
In any non-trivial application I'd assume the user would have to interface with more than one AWS service and having many different ways to pass credentials when there's an official(tm) way is irritating at least from my perspective.

tl;dr my vote is fully support 2, 4 and also keep 1 around, but mark it deprecated.

[Souler]

The reason behind the point 3 is being able to keep the config passed to the plugin a plain object. This allows to store the config on a json file (or any other plain text filetype) and load it on build time, which a lot of times is desireable too.

Maybe, pretending to handle any errors thrown by AWS.Credentials constructor is bit overkill, it doesn't even throw anything!.

Also, on the example 1 topic, I would add a log yellow warning with the deprecation notice.

My bottom line: also support example 3 (but dont overkill it), show a deprecation warning when using example 1.

[coveralls]

Coverage decreased (-9.02%) to 90.076% when pulling 5cc7697 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[line0]

Just a heads up, I've updated the PR to support all the requested cases. It's not ready to merge and almost completely untested. I'm still not convinced supporting Example 3 since it's a maintenance liability, takes some semi-educated guesses and then still fails to support all credential providers.
If that's still fine with you, I'll go ahead and complete the PR.

[coveralls]

Coverage decreased (-9.02%) to 90.076% when pulling 5bf55fe on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage decreased (-7.6%) to 91.473% when pulling 736d870 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.231% when pulling b5ad087 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.231% when pulling d156f6e on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.231% when pulling 3e755a2 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.231% when pulling 3e755a2 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.231% when pulling 3e755a2 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.242% when pulling 74825be on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.242% when pulling 74825be on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.242% when pulling bd7a371 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[coveralls]

Coverage increased (+0.1%) to 99.242% when pulling bd7a371 on line0:support-aws-credentials-object into e91659d on Upplication:master.

[line0]

@Souler This should now be ready to merge. I've also added two more changes:

1. rather than just allowing the user to change the AWS.config.signatureVersion, let them provide a config object to update AWS.config with. In my case i need to pass in a proxy, but there are other parameters users may want to touch (loggers, retry limits, ...)
2. made sure buckets are always created in the configured region (rather than the default region). Previously you could end up with a bucket in a region different to where your beanstalk environment resides, which would fail the build.

[line0]

@Souler any chance to get this merged