Feature/travis ci

[faceleg]

@pennycoder @cperryk first go at making the fakes3 gem and travis work together.

[faceleg]

@pennycoder s3ninja is best mock.

I haven't got it fully working though.

To try it out:

• Clone my fork, checkout feature/travis-ci
• docker run -p "9444:9444" 66pix/s3ninja
• Update your /etc/hosts to have bucket.localhost entry
• Export S3_ENDPOINT="localhost:9444/s3", keys from localhost:9444 homepage
• Run tests with npm run test

Observe the fail.

[pennycoder]

Should this new function also be documented in the readme?

[faceleg]

Yep, will do that if and when we actually manage to get CI working with S3Ninja. Which I am still not 100% convinced will be a thing.

Also I hacked this in and have no idea if it matches the expected format for a new API function.

[hemp]

My team is considering using this library and we had a question. Is the thought here once this PR merges, then the next step would be releasing updates to npm again? We are currently using this as a drop in for aws s3 cli and it works great (in our integration tests with minio in docker). Happy to contribute if there is a way we can.

ref #129

[faceleg]

I can't publish npm updates for the current module. npm updates are from https://github.com/faceleg/node-s3-client

I would question why you can't use the AWS node SDK, I personally use that over this library (admittedly my use case is limited).

[hemp]

@faceleg great point about the SDK and are sticking with it now. We were researching and looking for better S3 retry support than what the AWS node SDK offered and found this module. So that is how we became interested.

[faceleg]

I would recommend making a S3 retry wrapper around just that portion of the api (and putting it on GH!)

I like to think that a lot of the issues that this lib was originally created to help with have been patched out of the SDK by now (but like I said I have a very limited use case)