<div dir="ltr">This would be desirable.<div><br></div><div>It's unfortunately a bit of complexity included. As Alessandro said, the rendering tests are a good example of tests which are hard to maintain and - unfortunately - not well defined functions like we happen to have on e.g. database engine unit tests.<br></div><div><br></div><div>To recall, when we started with CI some 5 years ago we were in the situation that we had a set of tests, which randomly passed on some dev machines and some on others. So effectively you had no chance to know if a test doesn't pass because of your machine or your patch.</div><div><br></div><div>At least now we have a reference platform and know if a patch actually does cause changes. Which is the most important information.<br></div><div><br></div><div>Currently many of the tests are already cross platform. And nobody is actively writing <i>CI centric tests</i>. It's just a matter of fact that the tests have a requirement to <i>at least</i> pass on the CI env because it's the only thing that can be enforced.<br></div><div><br></div><div>When tests are updated to a new platform (ci or not), many of them will pass on a wider variety of platforms. Because bugs are fixed or they are made more generic. And some will just have reference images for one more platform added.<br></div><div><br></div><div>So whatever we do we will do a step into the right direction. But there will be no guarantee that every test passes on your machine except if you make them all pass on your machine - which would be very welcome!!</div><div><br></div><div>What you could also do is listing tests that are generic / platform independent (e.g. the expression tests would be a very good example) and then always just run these instead of the whole set of tests.</div><div><br></div><div>Matthias<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 6, 2020 at 11:29 AM Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</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">On Fri, Nov 06, 2020 at 05:07:40PM +1000, Nyall Dawson wrote:<br>
<br>
> - different Qt versions on Github vs Travis<br>
> - different underlying library versions (e.g. updated proj, gdal, and<br>
> others vs the older Travis build environment)<br>
> -  other differences in the build setup, e.g. different limits on the<br>
> environment under which the tests run<br>
> <br>
> Before we can make the switch and move away from Travis, we'll need to<br>
> update these tests and get as many of them passing as possible on<br>
> Github, and then handle the tricky job of backporting the test fixes<br>
> and Github action setup to the 3.16/3.10 branches.<br>
<br>
I'd recommend changing the tests to return success results with BOTH<br>
versions of Qt, proj, gdal etc. The goal would be making the testsuite<br>
pass on _developers_ machines, whatever libraries they are using.<br>
<br>
The CI-centric nature of QGIS testsuite has always been a problem for<br>
me as it makes it impossible to check the quality of changes locally.<br>
<br>
There are likely existing tickets addressing these issues.<br>
A 'testsuite' label exists. I'm not sure all the relevant tickets<br>
have the label applied, but it could be a good starting point:<br>
<br>
  <a href="https://github.com/qgis/QGIS/issues?q=is%3Aopen+is%3Aissue+label%3Atestsuite" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/issues?q=is%3Aopen+is%3Aissue+label%3Atestsuite</a><br>
<br>
--strk;<br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div>