Home

Welcome to the node-s3-uploader wiki!

Development Environment

Prerequisite

Docker >= v1.6
Docker Compose >= v1.2

Environment Variables

AWS_ACCESS_KEY_ID - AWS public key
AWS_BUCKET_NAME - AWS test bucket name
AWS_BUCKET_PATH - AWS test bucket path
AWS_BUCKET_REGION - AWS test bucket region
AWS_SECRET_ACCESS_KEY - AWS secret key

Run Tests

$ docker-compose run --rm dev npm test
$ docker-compose run --rm dev npm run watch

Commit Messages

Commit messages should follow the AngularJS Git Commit Message Conventions, this is the same standard implemented by tools like commitizen and conventional-changelog.

docs(CHANGELOG): fix breaking change
chore(release): 0.5.0
feat(template): add scope to breaking changes

Branches and Pull Requests

Branches and pull requests should have a single purpose such as "Implement feature X", "Fix bug X", please split multiple features or bugs in multiple pull requests. This way it will be easier to merge theme into the main line.

Consensus Seeking Process

This project follows a Consensus Seeking decision-making model.

All proposed changes to the project must be made in the form of a pull request to the repository (directly committing to a production branch of the repository is not permitted). The consensus seeking process will then follow via discussion by the project collaborators on that pull request. Changes deemed trivial by collaborators may be merged instantly by any collaborator, without waiting for consensus, so long as they leave a note explaining the reason for the merge.

Release Procedures

Releases are automated through wercker ci. To release a new version to npm do the following:

Bump the version in package.json according to SemVer
Commit the new version git commit -m 'chore(release): vX.Y.Z' package.json
Tag the release in git git tag -a 'vX.Y.Z' -m 'vX.Y.Z'
Push the new tag to master git push --tags origin master
Publish a new GitHub release for the new version

Release Candidates

It is common practice to ship release candidate versions as soon as possible after new features gets merged into master. This gives contributors and interested users the possibility to test out and give feedback on new functionality before it gets released publicly.

Release candidates follows the release procedures above but are versioned on the following format vX.Y.Z-rc.N where X.Y.Z is the next version according to SemVer, and N is an incrementing number for each release candidate until the final version has been released.