Test first touch

[navjotk]

No description provided.

[FabioLuporini]

Do we really want an entire new Travis build just for testing first touch ?

[navjotk]

Try all the tests once without first touch and once with. How are you imagining this differently?

[FabioLuporini]

not sure, a number of tests/examples parametrised over first touch?

[navjotk]

What are the advantages of that compared to a separate build?
The advantages of a separate build are:

• Having a separate build means all (new) tests are automatically run in both configurations unless explicitly turned off. As a corollary, we won't be missing bugs because someone forgot to update travis.yml to configure a new test to run with first touch. That seems like a good thing to me.
• Having a separate build means we are running tests in parallel so individual builds don't last as long.

[FabioLuporini]

I am under the assumption that we have constrained build capacity on our Travis account. Can you enlighten me here @mlange05 ?

[mlange05]

In theory we can run as many builders as we like (up to like 23 or something arbitrary). However, they won't all be run in parallel with each other, especially on busy days, so your overall overturn-time will still increase. I've rarely seen more than 4 in parallel, although that maybe a flaky observation, so keeping the number of builders reasonably small to achieve the desired coverage is still a good thing.

Regardless, of the number of builders, travis is still red, so we might want to address that one first. @navjotk

[navjotk]

Oh that's because I only added the first touch build to highlight the fact that first touch is broken again. I haven't actually fixed it yet. Is it a problem to leave this PR open as a reminder?

[navjotk]

This depends on #320 . Closing until the bug is fixed.