Reusable Travis CI setup

[honzajavorek]

Thanks for commitlint and for the CI setup tutorial! I like the pre-prepared shell script, which counts with all the possibilities which can happen when using GitHub and Travis CI, but currently I can only use it as part of my project by copy-pasting from the docs.

Since it's not two lines, but a bunch of them, many if/elses included, I'm wondering whether it would make sense to turn it into a separate package. I want to install commitlint on multiple repositories and I believe being able to do just sth like npm i commitlint-travis --save-dev instead of copy-pasting the script would make the maintenance of the repos easier as well as doing any updates if e.g. Travis CI or GitHub make any changes and the flow breaks.

What do you think? I'm happy to help.

[marionebl]

That is a good idea, setting up CI should really be easier. I wonder if a cli wrapper is the appropriate way to do this, though - we'd end up with commitlint-circle-ci, commitlint-appveyor, etc.

In my mind the current CI script concerns itself with determining the appropriate commit ranges for a (Travis) CI environment.

Perhaps a tool that does exactly that and plugs nicely intocommitlint would be the scaleable approach.

commit-range # detects CI environments automatically?
{from: 'a9385', to: 'e2357'}

# this api is just my cranky first shot
commitlint --range $(commit-range)

Let me know what you think!

[felixfbecker]

I am probably missing something, but I wonder why the script is so complicated? Shouldn't only $TRAVIS_COMMIT_RANGE contain exactly the information that's needed?

[marionebl]

@felixfbecker If recall correctly there were unsolved issues with $TRAVIS_COMMIT_RANGE: travis-ci/travis-ci#4596

[felixfbecker]

That can be worked around with by doing ${TRAVIS_COMMIT_RANGE/.../..} as stated in that thread

[honzajavorek]

I like the idea of the standalone commit-range "calculator" and --range being the API between those two. Of course, if the tool would be redundant, because sth. like ${TRAVIS_COMMIT_RANGE/.../..} is enough, that would be even better. But I'm no Travis CI commit range guru, so I'd leave that to others to verify.

[honzajavorek]

So far I came up with following simplification: apiaryio/dredd-transactions#116

#!/bin/bash
set -e
git remote set-branches origin master
git fetch --unshallow --quiet
git checkout master --quiet
git checkout - --quiet
./node_modules/.bin/commitlint --from=master --to="$TRAVIS_COMMIT"

I'm not sure whether this can be further simplified, but it seems to work for all the scenarios when I played with it.

[felixfbecker]

@honzajavorek what if the PR base is not master?

[honzajavorek]

That's good point. Doesn't happen very often, but happens to me as well 🤔 I guess using sth like ${TRAVIS_PULL_REQUEST_BRANCH:='master'} instead of just master could do the job.

[marionebl]

Hey, I took your improved script @honzajavorek and ran with it here:

• https://github.com/marionebl/commitlint/pull/151

Contrary to what I wrote in https://github.com/marionebl/commitlint/issues/99#issuecomment-338120450, I went with a spoecialized @commitlint/travis-cli package that exposes travis-commitlint.

Some code review on that PR would be super nice 🙇

It is intended to be used with zero configuration. I wonder if you would be interested in testing out a prerelease of this @honzajavorek @felixfbecker.