ci: simplified commitlint script

[marionebl]

• Introduce a new package @commitlint/travis-cli
• Expose new command @commitlint/travis-cli

ToDo

• git stash before git checkout
• git stash afterwards
• Check if unshallow is needed

Description

• Aborts noisily when invoked in non-Travis environment
• Infers commit range to lint automatically from Travis Ci env variables
• Will lint --from $TRAVIS_BRACH --to $TRAVIS_COMMIT
• Ensures required git range is available

Motivation and Context

• Setting up commit linting on Travis CI is too hard at the moment
  *@commitlint/travis-cli is designed to be zero-config on TravisCI
• Motivated by Reusable Travis CI setup #99

Usage examples

{
  "devDependencies": {
    "@commitlint/travis-cli": "5.0.1"
  }
}

script:
  - commitlint-travis

How Has This Been Tested?

• unit tests
• dogfeeding

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[felixfbecker]

I don't understand this - why log the error twice? why not use console.error(err); process.exit(1); instead?

[felixfbecker]

execa returns a Promise so you shouldn't need to use the Promise constructor

[felixfbecker]

why npx?

[marionebl]

The over-simplified answer is: I introduced npx at one point to ensure the dev setup works regardless of the current state it is in. I'll keep them in travis-cli for now to be consistent, will remove them from all packages in one go in the near future.

[marionebl]

Thanks for the review @felixfbecker!