Initial Adoption of Continous Deployment using semantic-release

[keplersj]

To ease the modification/contribution to publish pipeline there has been some discussion of adopting a continuous deployment system for AtomLinter packages. To accomplish this we are making use of semantic-release and @semantic-release/apm-config.

This pull request has been dynamically created using a script. While the result is not perfect, it does accompish most of the grunt work of adopting continous deployment. There is some reconciliation that needs to be done before this can be merged.

Among the things needed to be reconciled, an APM Token and GitHub Token will need to be added to this repo's continous integration (most likely Travis CI) configuration for automated deployments to work.

Again, this Pull Request has been created by a script made by @keplersj. Please mention him if something has gone wrong, and he'll be happy to help.

ref: AtomLinter/Meta#18

cc: @Arcanemagus

[Arcanemagus]

@AtomLinter/linter-codeclimate @cgalvarez Any issues with adopting this functionality? As it stands this would mean requiring the Conventional Commits standard for the commit messages so the tool will know what type of release (if any) should be made.

[cgalvarez]

I've already used semantic-release for some projects of mine (atom-coverage is a public one). I agree it really helps with automatic releasing/deployment/publishing.

That said, I've had some issues with it in the past, which leads me to provide some insights about this PR:

• npx is a NPM package that is not listed in the project dependencies (neither development nor production) and it's not installed globally on TravisCI. Maybe I'm wrong, but I think it should be installed in a before_script key to have it available prior to executing npx semantic-release on the deploy stage.
• We should add the semantic-release badge to the README.md too, so anybody that reaches the project knows immediately that s/he must stick with it.
• @commitlint/config-conventional enforces conventional-commits. Since semantic-release can be configured to support a variety of conventions, I think we should remark it too with another badge.
• I still have troubles with auto-updating the changelog on deployment in my projects. Just commenting it, I suppose @keplersj 's PR already manages it 😉
• I think the current TravisCI for this PR fails because of old config (60s vs the current 5min after merging Fix/one spawn per project #83), so it has nothing to do with this PR itself.

[Arcanemagus]

npx is a NPM package that is not listed in the project dependencies

This PR is just a starting block, there are many additional changes that are required before it can be merged. This is an example of a simpler complete version of this PR: AtomLinter/linter-phpmd#118, while alternatively it can get as messy as AtomLinter/atom-linter-perlcritic#51 + AtomLinter/atom-linter-perlcritic#52 + AtomLinter/atom-linter-perlcritic@7d1b630 to get fully working 😆.

We should add the semantic-release badge to the README.md too, so anybody that reaches the project knows immediately that s/he must stick with it.
@commitlint/config-conventional enforces conventional-commits. Since semantic-release can be configured to support a variety of conventions, I think we should remark it too with another badge.

Great ideas! Note that part of this is that commits can't be merged without fitting into the commit standard, and assuming the dev runs npm install a precommit hook is installed that checks the message before it even gets into the local repo.

I still have troubles with auto-updating the changelog on deployment in my projects.

Interesting, I've yet to see an issue with this on the ones done so far.

---

I'm happy to take care of getting this merged and working, just wanted confirmation from the people working on it that the Conventional Commits standard wouldn't be an issue 😉.

[Arcanemagus]

Cool, deploy step worked with no further changes needed 😀.