Re: [PATCH v2 3/3] travis: run tests with GIT_TEST_SPLIT_INDEX

[Lars Schneider <larsxschneider@gmail.com>]

> On 04 Jan 2018, at 21:13, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> 
> On 12/18, Lars Schneider wrote:
>> 
>>> On 17 Dec 2017, at 23:51, Thomas Gummerer <t.gummerer@gmail.com> wrote:
>>> 
>>> Split index mode only has a few dedicated tests, but as the index is
>>> involved in nearly every git operation, this doesn't quite cover all the
>>> ways repositories with split index can break.  To use split index mode
>>> throughout the test suite a GIT_TEST_SPLIT_INDEX environment variable
>>> can be set, which makes git split the index at random and thus
>>> excercises the functionality much more thoroughly.
>>> 
>>> As this is not turned on by default, it is not executed nearly as often
>>> as the test suite is run, so occationally breakages slip through.  Try
>>> to counteract that by running the test suite with GIT_TEST_SPLIT_INDEX
>>> mode turned on on travis.
>>> 
>>> To avoid using too many cycles on travis only run split index mode in
>>> the linux-gcc and the linux 32-bit gcc targets.
>> 
>> I am surprised to see the split index mode test for the linux 32-bit
>> target. Is it likely that a split index bug appears only on 32-bit? 
>> Wouldn't the linux-gcc target be sufficient to save resources/time?
> 
> I'm not sure it's particularly likely for a bug to appear only on
> 32-bit builds.  It also doesn't seem to take too long to run, so I
> thought I'd add it just in case, but I'm happy running the tests only
> in the 64-bit builds if that's preferred.

CI running times naturally add up over time as more and more stuff is
tested. That's why I would argue testing GIT_TEST_SPLIT_INDEX on 64-bit
is probably sufficient. However, I am not really familiar with 
GIT_TEST_SPLIT_INDEX. 

There is no right or wrong here and either way is fine with me. 
I just wanted to express my "keep an eye on CI time" concern.


Thanks,
Lars