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 tools: - 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?) Regards Antoine.
