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
have a convincing example to show why such debug asserts are important
and when can a test pass despite a debug assert failing.
When I am doing development on Quickstep, I typically use a local debug
build, but only one configuration (e.g. VECTOR_COPY_ELISION flag set to
none or selection). If we take out debug builds out of Travis, how can
the reviewer be assured that I have tested all the configurations? Also,
it is time consuming. Hence, Travis.
To summarize, I would mention two points:
1. I am suggesting that we use those debug build configurations on
travis which have not been timing out. For the remaining configurations,
we should rely on the developer testing them out on their local machine.
Meanwhile, we should think of speeding up builds for those configs which
are timing out.
2. Let us not unilaterally change the CI configurations, unless there is
a consensus.
On 11/22/2016 11:54 PM, Zuyu Zhang wrote:
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 we do not need such info at all. We only care whether the CI
results pass.
I do recommend a PR submitter should develop using and test with the
debug build.
On the other hand, the template code explosion, particularly the
expressions and operators part, typically results in OOM using GCC,
and thus we set the make job to one.
Cheers,
Zuyu
--
Thanks,
Harshad
