Automate releases on CI about atom-linter HOT 14 OPEN

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

from atom-linter.

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

from atom-linter.

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

from atom-linter.

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

from atom-linter.

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

from atom-linter.

np, I've forgotten before also.

from atom-linter.

Any particular benefits of doing this?

from atom-linter.

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

from atom-linter.

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

from atom-linter.

@steelbrain You can trigger it for new tags only.

from atom-linter.

That's appealing

from atom-linter.

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.

from atom-linter.

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.

from atom-linter.

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

from atom-linter.