Tag branches based off of Github merges

TL;DR?

If the last commit in your repo is "Merge pull request #121 from myUser/major/changes" running tagger will bump the major tag number for your project via npm version using magic to determine what sort of change your PR contained.

What is this thing?

tagger looks in your repo for the last commit. If it's a merge from GitHub, it looks at the merge's original branch name and makes a rough guess at What kind of change it was (major, minor, or patch), and then bumps the package.json for your project via npm version [major, minor, or patch]

What's this with the merges?

We're assuming that your feature branches follow this naming format:

[type of change]/[name of feature branch]

So, given that, we look at [type of change] and find the change type from the following table:

Prefix | Type of change -------- | --------------- feature | major major | major task | minor chore | minor minor | minor

Anything else is considered a patch change

Why?

We are really lazy developers and want to be able to rev our package versions through our build process. Each time we run a build against master, if the head of master is a merge commit from GitHub, we bump the version.

Basically, our post-test step in Jenkins looks like:

if [[ $test_passed && $branch == 'master' ]]; then
  tagger && git push --tags
fi