Automate releases on CI

[SpainTrain]

No description provided.

[keplersj]

I've been experimenting with this idea for linter-clang and it's a bit more complicated that it may appear to be. I've started an issue with Travis CI about this here: travis-ci/dpl#378

[SpainTrain]

Remember that this is an npm package, not an apm package.

npm packages are straightforward to automate on travis:

https://github.com/LiveSafe/gulp-html5-lint/blob/master/.travis.yml

[SpainTrain]

(docs https://docs.travis-ci.com/user/deployment/npm/)

[keplersj]

@SpainTrain my bad, saw the subject in my email and pounced. :D

[SpainTrain]

np, I've forgotten before also.

[steelbrain]

Any particular benefits of doing this?

[Arcanemagus]

You can't accidentally publish a release that isn't passing the builds, also you don't have to deal with it 😉.

[steelbrain]

So here's the question, CI is triggered for PRs, if somebody bumps the version in a PR, would that publish a release?

[keplersj]

@steelbrain You can trigger it for new tags only.

[steelbrain]

That's appealing

[keplersj]

Right? I've done it with RubyGems before, but then I set it to only release pre-releases and I would push full releases locally.

[SpainTrain]

Deployments and releases of any software should be automated because:

• There is no log or auditable artifact when publishing manually. Publishing via CI creates logs in the commit history and in the CI system, so everyone knows who published which commit.
• Removal of human error (Landon mentions a couple, but there are plenty of other errors e.g., didn't update remotes, on a branch other than master, ...)
• Collaborators can publish new versions without needing permissions to the package on the registry
• Committing compiled assets to source control is an anti-pattern, publishing on CI makes it easier to avoid
• Less work, more time to do cooler stuff :-)

The best approach IMO is for CI to handle bumping, tagging, and publish/deploy. The way this generally works is:

1. In merge commit (for PR) message add directive release v+<bump-type> (patch | minor | major)
2. In deploy section of CI config, check for the directive. If present:
   1. Run whatever compile or build tasks are needed
   2. Bump and tag based on directive (with npm this is npm version <bump-type>)
   3. Run publish/deploy task. With npm this is of course npm publish. However, Travis has native support for npm publishing. In this case, using tag-based trigger that @kepler0 mentions is better.

I have used the approach of bumping in a PR and advise against using it. I have found the approach above to be easier to find/trace in commit logs, less error-prone, and faster/easier.

[keplersj]

Hello from 2 years into the future! semantic-release solves this very elegantly with npm packages now.

[Arcanemagus]

Hah! That does solve it here since this is just an NPM package, not APM like the actual providers.