Won't moving CI away from Travis to our own infrastructure mean that we
won't get any CI on our personal forks?

On Wed, Jul 17, 2019 at 8:23 AM Wes McKinney <wesmck...@gmail.com> wrote:

> On Wed, Jul 17, 2019 at 10:22 AM Wes McKinney <wesmck...@gmail.com> wrote:
> >
> > 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:
> >
>
> *missing crucial detail: "builds on personal forks"
>
> > * 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
>

Reply via email to