lint-commit-messages does not work by default on Travis CI

[davidchambers]

Travis CI only checks out the feature branch, so git log --no-merges --format=%s master.. returns no results.

I see two possible solutions:

• document Travis CI configuration for checking out the default branch; or
• compare to the remote's default branch rather than to the local repository's default branch.

[davidchambers]

After several hours of trial and error I succeeded in getting lint-commit-messages to work on Travis CI. I arrived at this configuration:

before_script:
  - git fetch origin refs/heads/master:refs/heads/master
  - if [ "$TRAVIS_PULL_REQUEST_BRANCH" ] ; then git checkout -b "$TRAVIS_PULL_REQUEST_BRANCH" ; fi

Travis CI performs two checks: push and pr. In both cases the repository is in a “detached HEAD” state. Semantically it would be correct to check out the pull request branch in the push case (since HEAD points to the same commit as the branch pointer), but TRAVIS_PULL_REQUEST_BRANCH is only defined in the pr case. So, we give the detached head the name of the pull request branch in the pr case and let the “branch name” be something like fantasyland/HEAD in the pull push case. The length of the pull request branch name is thus checked in the pr case but not in the pull push case.

[Avaq]

In the last few sentences you introduce the term pull. Did you mean push instead?

[davidchambers]

Indeed. I knew I shouldn't try to explain this at three in the morning!

[Avaq]

I did notice the post' time, yes. ;)

[Avaq]

I understand the solution, but I don't understand the problem.

Travis CI only checks out the feature branch

Do you mean that it fetches only the feature branch?

[Avaq]

If so, then only the initial step of your before_script should be necessary, right?

[davidchambers]

Do you mean that it fetches only the feature branch?

Yes. By default git branch --list shows only the detached head.

If so, then only the initial step of your before_script should be necessary, right?

The two lines serve different purposes: the first creates a local master branch; the second ensures that the name of the pull request branch is used when checking the length of the message of the prospective merge commit.

-Merge pull request #999 from fantasyland/HEAD
+Merge pull request #999 from fantasyland/davidchambers/scripts

[Avaq]

the second ensures that the name of the pull request branch is used when checking the length of the message of the prospective merge commit.

But shouldn't this particular commit (the detached head) be ignored by --no-merges, seeing as it is a merge commit from $TRAVIS_PULL_REQUEST_BRANCH into master?

[davidchambers]

The script does two distinct things: lints commits on the pull request branch and lints the prospective merge commit. The second check does not depend on the output of git log.