The boards must have networking, so that we can extract the dEQP .xml results to
artifacts on GitLab, and so that we can download traces (too large for an
initramfs) for trace replay testing. Given that we need networking already, and
-our dEQP/piglit/etc. payload is large, we use nfs from the x86 runner system
+our dEQP/Piglit/etc. payload is large, we use nfs from the x86 runner system
rather than initramfs.
See `src/freedreno/ci/gitlab-ci.yml` for an example of fastboot on DB410c and
Since we're going the TFTP route, we also use NFS root. This avoids
packing the rootfs and sending it to the board as a ramdisk, which
-means we can support larger rootfses (for piglit testing), at the cost
+means we can support larger rootfses (for Piglit testing), at the cost
of needing more storage on the runner.
Telling the board about where its TFTP and NFS should come from is
If a test farm is short the HW to provide these guarantees, consider dropping
tests to reduce runtime. dEQP job logs print the slowest tests at the end of
-the run, and piglit logs the runtime of tests in the results.json.bz2 in the
+the run, and Piglit logs the runtime of tests in the results.json.bz2 in the
artifacts. Or, you can add the following to your job to only run some fraction
(in this case, 1/10th) of the dEQP tests.
- It must not introduce a regression - be that build or runtime wise.
.. note::
- If the regression is due to faulty piglit/dEQP/CTS/other test
+ If the regression is due to faulty Piglit/dEQP/CTS/other test
the latter must be fixed first. A reference to the offending test(s)
and respective fix(es) should be provided in the nominated patch.