quickstep-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harshad Deshmukh <hars...@cs.wisc.edu>
Subject Re: Travis CI 50-minute Timeout
Date Thu, 24 Nov 2016 18:14:35 GMT
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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message