| Summary: | Gather and allow reporting all types of errors, not just task failures | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] Error Reporting tool | Reporter: | Paul Eggleton <bluelightning> | ||||||||||||
| Component: | Error Reporting Tool | Assignee: | Aníbal Limón <anibal.limon> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Libertad <libertad.gonzalez.de.la.cruz> | ||||||||||||
| Severity: | enhancement | ||||||||||||||
| Priority: | High | CC: | alexandru.c.georgescu, belen.barros.pena, benjamin.esquivel, jose.perez.carranza, joshuagloe, leonardo.sandoval.gonzalez, michael.g.wood, richard.purdie | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | 2.2 M1 | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Multiple | ||||||||||||||
| Whiteboard: | GUI desing available | ||||||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||||||
| Verified: | Documentation change: | Don't know | |||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Paul Eggleton
2015-04-08 16:13:40 UTC
Is this something that needs implementation in the autobuilder's error submission mechanism or more generally? No, this is more on the build system side of things i.e. meta/classes/report-error.bbclass - at the moment it only handles errors that trigger a bb.build.TaskFailed event. I just took a quick look and it seems like it's not quite as simple as just listening for additional events - parse errors should trigger a bb.command.CommandFailed event but that's probably too generic, and there's no event you can listen for at that level if bb.error() is called, so the likelihood is that you would need to add code into bitbake to trigger events that you could then listen for in the class. Moving it to 2.2 given that the error reporting mechanism needs support in bitbake. Anibal, please add the additional bug for that support. From a recent discussion, an examples of uncaught errors would be a parse errors in recipes, such as the LICENSE information being missing. (In reply to comment #4) > From a recent discussion, an examples of uncaught errors would be a parse > errors in recipes, such as the LICENSE information being missing. This kind of errors are took into account now the plan is to have a recipe and bitbake errors type. The bitbake errors will cover the parsing errors so then we could split the bitbake errors into categories. I'm starting to work on it [1] currently i only split the code for generate the JSON file to is own module in order to be able to execute the new errorreport.py script in other enviroment like AB because for catch bitbake errors is needed to execute bitbake and monitor the retcode and log output. [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=alimon/error_report Hi, I modified the AB for generate bitbake exception/error reports [1] this is almost done, i upload a example of the report to my own instance of ERT and some changes in the UI are needed. In summary i used the same fields for publish the bitbake information next are the differences in the bitbake report the another fields are the same, Recipe: "Bitbake" Recipe version: "1.31.0" # As an example of bitbake version Task: "bitbake -c core-image-sato" # As an example of bitbake command I'll attach two screenshots of my ERT instance for review the UI. [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=9293#c3 Created attachment 3193 [details]
bitbake error main page
Created attachment 3194 [details]
bitbake error detail
Created attachment 3207 [details]
Design - Display all error types
A design proposal based on my conversations with Aníbal Limón and Richard Purdie. Please read and comment as needed. I have mainly 2 concerns:
1. I've removed the recipe, recipe version and task information from the errors table, since those fields are no longer common to all errors. They are now shown in the error details page. The change seems to somehow make the table much less informative, but that could be just my perception, and not be the case from the SWAT team's perspective. Check page 3 of the design document and let me know what you think.
2. Aníbal's examples seem to show all the commands executed up to the point of failure. In the design, I suggest we show only the command that failed (see page 6 of the document). If the full command chain is useful, let me know.
Created attachment 3213 [details]
Design - Display all error types
Add a column to the errors table with heading "Failure" that shows the recipe:task that failed for recipe errors, and the command that failed for all other errors (see page 4 for changes).
Belen: Thanks, the revised design is much better and should be more useful to SWAT. What is the reasoning that the Failure column isn't sortable? I ask since sorting that is one of the things I do tend to do when using the current error reporting system... Created attachment 3214 [details]
Design - Display all error types
Change the "Failure" column to be sortable (see page 4).
The ERW is ready for receive Bitbake and OE-seltest errors, http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/commit/?id=e63e5bd6bec69c0d58de6ddbdf7889a53dd4d256 The remaining part is to enable AB to send Bitbake, OE-seltest the code is now on review and needs integration and deplyment, https://bugzilla.yoctoproject.org/show_bug.cgi?id=9293 |