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.
In the case of Appveyor for example, I don't think we need the exhaustive build matrix on each commit, but it would be useful to be able to validate if desired (and in an automated way) that the NMake build works properly. This could be automated with the crossbow build tool. 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). We can verify that the toolchain will successfully build automatically via ExternalProject in a nightly. - Wes On Mon, Aug 6, 2018 at 7:23 AM, Antoine Pitrou <anto...@python.org> wrote: > > Hello, > > Our CI jobs are taking longer and longer. The main reason seem not to > be that our test suites become more thorough (running tests actually > seems to account for a very minor fraction of CI times) but the combined > fact that 1) fetching dependencies and building is slow 2) we have many > configurations tested on our CI jobs. > > The slowest job on our Travis-CI configuration routinely takes more 40 > minutes (this is for a single job, where everything is essentially > serialized). As for AppVeyor, the different jobs in a build there are > mostly serialized, which balloons the total build time. > > If we ever move parquet-cpp into the Arrow repo, this will probably > become worse again (though it might be better for parquet-cpp itself, > which doesn't seem to have received a lot of care on the CI side: for > instance, parquet-cpp AppVeyor builds are abysmally slow). > > I think we will have to cut down on the number of things we exercise on > the per-build CI builds. This can be done along two axes: > 1) remove some build steps that we deem non-critical or even unimportant > 2) remove some build configurations entirely (for instance I don't > understand why we need a "static CRT" build on Windows, or worse, why we > need to have NMake-based builds at all) > > Any thoughts? > > Regards > > Antoine.
