Replace semantic-release dependency with TravisCI build stages

[orangejulius]

This change moves semantic-release out of dev-dependencies, but keeps its functionality by calling semantic-release as usual in a release TravisCI build stage. There are several advantages to this method:

1.) semantic-release is run only after all builds succeed. Our previous approach could have theoretically run semantic-release when some Node.js versions failed with the current code

2.) semantic-release (and it's many dependencies) are removed from node_modules. This increases the speed of npm install in all cases, and reduces the size of our Docker images by 20MB (from 284MB to 264MB)!
Since the only time semantic-release is needed is on TravisCI anyway, it seems pointless that every installation of Pelias should include it.

3.) Because semantic-release is not in package.json, Greenkeeper will not attempt to update it. Semantic release updates very frequently, and each update attempt seems to have a decent chance of experiencing a random TravisCI failure, causing unwanted notifications.

There are probably downsides to this approach. For example, we should consider pinning the major version of semantic release during install.

Additionally, and for obvious reasons, we can't fully test this change until it's merged to the production branch. We should consider testing it first on a lower priority repository.

If this change does work well, we should consider adopting it everywhere.

[missinglink]

Sounds like a good idea to keep CI stuff in CI.

One issue you noted was managing the CI config, versioning etc.

Would it be a good idea to have a pelias/CI repo which contained all the CI scripts?

The advantage would be transparency and a familiar workflow for bug reports and issue fixes.

Ie. Travis clones the CI repo and runs all scripts inside before running tests.

[orangejulius]

Great idea, I had been thinking about that as well. I've made https://github.com/pelias/ci-tools and added scripts to run semantic release (from a pinned version), and our Docker build. Both Travis and Circle are updated to use it. I'm using the curl url | bash - trick, which I think is safe given it's a URL we control. Any thoughts?

[orangejulius]

Update: another benefit of this method has been discovered: it surfaces semantic-release failures better.

We have had many semantic-release runs fail, causing botched releases. This is especially relevant since NPM recently invalidated all credentials, and that is a common cause of failed runs.