Hi Harshad,
I could add back the debug build with LLVM. Thanks!
Cheers,
Zuyu
Hi Zuyu,
My understanding of continuous integration is that the PR reviewer
should be rest assured that the code works correctly and he or she can
focus on the reviewing aspect. I agree that if the tests pass in release
build, they should in principle also pass in the debug builds. I don't
ha
Hi Harshad,
I don't think we need the debug build in Travis CI, as I believe both the
release builds and the debug build should produce the same results for a
PR, although the latter in a test failure case, would provide additional
info, like DEBUG_ASSERT as you mentioned. But as the PR reviewers
As a stop-gap measure, can we all run the debug build on our local machine
before opening a PR? Harshad makes a good point about getting into a mode where
the DEBUG ASSERTS are never checked.
I’d also suggest that we make a note of this in each PR description so the
reviewer does not have to a
One option to lower the compilation time is to reduce the template code
explosion. Based on the discussion on the PR:
https://github.com/apache/incubator-quickstep/pull/129 it seems that
removal of a storage format is on the cards. I hope it helps in avoiding
the Travis timeout.
On 11/16/201
Hi Zuyu,
Completely disabling the debug builds is not ideal, in my opinion. A lot
of DEBUG ASSERT statements, which are potentially quite useful in
debugging issues, only fire up in debug builds. I see from some of the
previous pull requests that not all debug configuration run for 50+
minute
Hi,
I would like to discuss how to avoid the Travis CI timeout issue in both
the master branch and the PRs.
The problem is that now Travis CI precisely kills all jobs running for 50
minutes, but unfortunately two GCC debug builds run about 1 hour.
I would suggest that the Travis CI only tests fo
