firefox 152.0, test changes#1004
Conversation
Release notes: https://www.firefox.com/firefox/140.12.0/releasenotes/. Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
OldManYellsAtCloud
force-pushed
the
152.0
branch
7 times, most recently
from
297eecb to
e1180e3
Compare
|
It seems that weston fails to start up on wrynose with 32-bit arm when compiled with musl :(, which puts testing on hold for a bit until I (or anyone else) figures out what's wrong |
|
First I bisected oe-core to find a problem with musl. Then once I fixed that locally, it was still broken, so i bisected oe-core once again this time with my patch, to find that it was broken later by a mesa upgrade also. For now I give up - I will blacklist arm+musl+wayland combo on master and wrynose in the CI. I have filed a bug at YP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=16334 |
Release notes: https://www.firefox.com/firefox/152.0/releasenotes/ https://www.firefox.com/firefox/152.0.1/releasenotes/ https://www.firefox.com/firefox/152.0.2/releasenotes/ https://www.firefox.com/firefox/152.0.3/releasenotes/ Added a new patch (riscv-js-simulator-error.patch) to fix compilation for riscv64 architecure, which in theory can be removed with the next major upgrae. Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
The PARALLEL_MAKE OE variable has been ignored until now, Firefox was built with the number of jobs determined by mach (which is usually the number of CPU cores). To be able to control this number, pass the PARALLEL_MAKE variable value as a custom make flag to mach. Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
OldManYellsAtCloud
force-pushed
the
152.0
branch
4 times, most recently
from
c222c70 to
4fbf71c
Compare
Originally the CI jobs were running for all supported Yocto releases, 4 arches and 2 libc implementations, all tested with x11 only. This is taking a long time already, and adding a single new dimension to the test matrix would double the execution time. Change the logic a bit: still test all Yocto releases and 4 arches, but for each build pick a random libc implementation (musl, glibc) and a random display system also (x11 or wayland). Though on a very short term this might shrink the test coverage somewhat, on the long run it should bring wider coverage than the previous state. Note: arm32+musl+wayland testing on wrynose and master branches disabled, because it seems that core-image-weston is broken with this config. YP bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=16334 Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
OldManYellsAtCloud
force-pushed
the
152.0
branch
from
4fbf71c to
223e179
Compare
|
One last note: in the workflow.yml file the docker image got a new volume path. That's a temporary measure: during debugging my sstate folder outgrew its drive, and had to move it to a bigger one. I intend to trim that folder and reverse that change with the next upgrade. Also, since Mozilla has meanwhile released 152.0.3, I bumped the recipe to that version. But all in all, this is ready from my end. |
2 participants
This PR contains 2 major-ish changes - but would like to avoid running the CI multiple times on the same recipes.
I'd like to write a couple of words about the latter change.
Until now testing happened for all stable Yocto releases (+master), with 4 CPU platforms, 2 libc implementations, executed only on x11.
This already takes quite a while to finish, and adding even a single new dimension to the test matrix doubles the execution time.
But I would like to test a bit more aspects than what's done currently. This change still builds and tests both Firefox recipes for all Yocto releases (+master), with 4 CPU platforms. However for each run the libc implementation (glibc or musl) and the display system (x11 or wayland) are randomly selected.
A drawback is that some (random) previously tested configurations are not tested in each CI run.
As an expected benefit the test coverage will be higher just after a few run, I hope this will make the layer more robust. Also, the test execution time should be somewhat shorter (at least from the next upgrade, after I managed to weed out the bugs from this PR that I missed during preparation). It should be also easier to add new tested aspects with this random method without unacceptably big execution time penalty.
One extra small change in this PR: the
PARALLEL_MAKEvariable was ignored so far during build. This should be now fixed.