hi folks -- I noticed this last night on https://github.com/apache/arrow/pull/4841 and it surprised me. Others may not be aware.
We have been using builds on Appveyor and Travis CI to decide whether to merge PRs. The trouble is these builds are not equivalent to the builds that Travis runs inside the PR (using the apache/arrow build queue). The differences are: * They do not take into account changes in master (IOW to test if the build works after `git merge`) * They only test the latest commit versus the previous one in the branch This latter item is insidious, because of the `detect-changes.py` script. Suppose that you have a large PR that touches many components, and you push a commit that only affects one of them. Then the detect-changes.py script will cause Travis to only run builds for the affected component in the most recent commit. Here's an example of such a spurious build https://travis-ci.org/wesm/arrow/builds/559745190 There are a few ways we can mitigate this last issue: * If you need a faster build, you can squash your commits and rebase on master before pushing to make sure that Travis "sees" everything. Note this still carries risk of conflicting changes in master causing a broken build post-merge * We can change the Travis configuration to try to detect whether or not we are testing a PR -- the detect-changes.py logic is really only intended to speed up builds in apache/arrow Overall, I think we need to accelerate our exodus from Travis CI since it's hurting the project's productivity to be waiting so long on builds. We've moved a couple of jobs to be Docker-based but we have quite a lot more work to do to decouple ourselves. Thanks Wes
