<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 10, 2019 at 11:54 AM Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 11/10/19 11:42 AM, Sandro Santilli
wrote:<br>
</div>
<blockquote type="cite">
<pre>On Sun, Nov 10, 2019 at 09:20:11AM +0100, Alessandro Pasotti wrote:
</pre>
<blockquote type="cite">
<pre>Just one thing I would recommend investing a bit more time and money: to be
able to run a Travis-like test suite locally
</pre>
</blockquote>
<pre>+1
I can't remember the last time I had a successful `make check`, bust
must be decades ago... Improving the ability for devs to run testsuite
locally is a huge asset. I think it goes along the lines of:
- Only run tests that can be run on the machine, given the available deps
... and WARN at build/test time about tests being skipped,
to hint developer about improving the test coverage
- Ensure running the tests doesn't mess up with your worktree
See <a href="https://github.com/qgis/QGIS/pull/31980" target="_blank">https://github.com/qgis/QGIS/pull/31980</a>
- Make it easy for devs to run single, specific tests, to help
when changing a single specific spot of the codebase</pre>
</blockquote>
<p>See
<a href="https://docs.qgis.org/testing/en/docs/developers_guide/unittesting.html#run-your-tests" target="_blank">https://docs.qgis.org/testing/en/docs/developers_guide/unittesting.html#run-your-tests</a>
, it says<br>
</p>
<p>> If a test fails, you can use the ctest command to examine
more closely why it
failed. Use the <code><span>-R</span></code>
option to specify a regex for which tests you want to run
and <code><span>-V</span></code>
to get verbose output:</p>
<div>
<div>
<pre>> <span></span>$ ctest -R appl -V
</pre>
</div>
</div>
<p>Is there more required?</p></div></blockquote><div><br></div><div>That's unfortunately not enough, what I was talking about it run test locally in the exactly same environment that Travis uses, I tried to document part of the workflow in <a href="https://github.com/qgis/QGIS/tree/master/.docker">https://github.com/qgis/QGIS/tree/master/.docker</a> but that's not enough to run the tests (I mean all of them including spelling, clazy and all the other checks that are run on Travis and that are not in the pre-commit hook).</div><div><br></div><div>There are times when being able to run Travis locally and interactively ssh into the containers a make changes is the only option.<br></div><div><br></div><div>So, first thing is to have a pre-commit that runs **all** the checks that are run on Travis, second is to be able to execute Travis environment locally.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<blockquote type="cite">
<pre></pre>
<blockquote type="cite">
<pre>So, IMHO long life to PRs and Travis for the time being but we need to give
to the developers the tools to run locally all checks that Travis runs
remotely so that they are reasonably sure ("reasonably" because Travis
random unrelated failures are always around the corner) that the build will
pass and they will be able to debug a Travis failure locally without
waiting for hours.
</pre>
</blockquote>
<pre>Now I realize you're talking about travis-like, that's also something
good to have, but as it would likely take much more upfront bandwidth
(docker image download?) and space (docker image) and time, it is also
good to support more lightweight testing.
--strk;
</pre>
</blockquote>
<blockquote type="cite">
</blockquote>
</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>