T11616 bisection report with logs#99
Conversation
Pass the full email options dictionary to get the subject string and use it as-is in the bisection email body. This shows aligns it with the build and boot reports, and also the subject has all the needed information (kernel revision, test plan, platform...). Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Add the CPU architecture to the bisection report. This is especially useful for platforms which have multiple possible architectures such as QEMU. Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Get the actual test suite name from the bisection meta-data rather than hard-coding it as "boot". Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
With the recently added support for bisection on linux-next and based on feedback with reports sent so far, tweak the information shown to make it easier to find the details about the failure that triggered the bisection and what the result was. The "good" information is not that helpful and sometimes misleading as when bisecting trees like linux-next, a different "good" merge-base is found to start the bisection. So the details about the "good" known commit are removed, the biseciton log at the bottom of the report will still show which commit was used to start the actual bisection. * add direct links to the test (boot) logs on storage.kernelci.org * replace good/bad details links with direct link to the "bad" boot on the frontend * replace good/bad revision numbers with just "start" which is the bad commit that triggered the bisection Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
|
Here's a sample report from a locally run bisection: I'm not 100% happy with the "start" and "detail" names, but I think the information they're pointing at is what is needed in the report. The issue with bisections is that there are 2 bad commits: the one that started the bisection and the one that was found by the bisection. Maybe I should just put something like "Bad revision that started the bisection: " and "Breaking change found by the bisection: ". |
|
It does now say it's a boot bisection which helps a lot. For start how about "Good commit" or something, mirroring the terminology used in the bisect command line UI? |
|
The "start" is actually the bad commit that caused a regression, I'm not showing the good commit any more. It removes a source of confusion especially with bisections on linux-next which take another good commit as a base (from mainline/master). |
|
Tested OK on staging. Merging now as it's already some improvement, will do another round next week to clarify further the distinction between the initial bad commit that triggered the bisection and the bad commit found by the bisection. |
Improve bisection email reports with direct links to the test logs and adjusted information to make it clearer what triggered the bisection and what the result was.