[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Re-think CI strategy?

Le 06/08/2018 à 13:42, Wes McKinney a écrit :
> hi Antoine,
> I completely agree. Part of why I've been so consistently pressing for
> nightly build tooling is to be able to shift more exhaustive testing
> out of per-commit runs into a daily build or an on-demand build to be
> invoked by the user either manually or by means of a bot. If you
> search in JIRA for the term "nightly" you can see a lot of issue that
> I have created for this already.

My worry with nightly jobs is that they doesn't clearly pinpoint the
specific changeset where a regression occurred; also, since it happens
after merging, there is less incentive to clear any mess introduced by a
PR; moreover, it makes trying out a fix more difficult, since you don't
get direct feedback on a commit or PR.

So in exchange for lowering per-commit CI times, nightly jobs require
extra human care to track regressions and make sure they get fixed.

> it would be useful to be
> able to validate if desired (and in an automated way) that the NMake
> build works properly

I guess the main question is why we're testing for NMake at all.  CMake
supports a range of different build tools, we can't exercise all of
them.  So I'd say on each platform we should exercise at most two build
  - Ninja, because it's cross-platform and the fastest (which makes it
desirable for developers *and* for CI)
  - the standard platform-specific build tool, i.e. GNU make on Unix and
Visual Studio (or "msbuild") on Windows

> I think we can also improve CI build times by caching certain
> toolchain artifacts that are taking a long time to build (Thrift, I'm
> looking at you).

The 40+ minutes Travis-CI job already uses the toolchain packages AFAIK.
 Don't they include thrift?

(another thought: when do we want to drop Python 2 compatibility?)