Capture failed build data earlier
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest4 patches 1 replyIn review
- v23 patches 2 repliesSuperseded
- v13 patches 1 replySuperseded
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | command: fire CommandExecution event before a command runsbitbake/ bitbake/ | +13 | 0 replies | |
| 2/4 | toaster: remove build_name from Build propertiesbitbake/ | +0 | 0 replies | |
| 3/4 | toaster: create Build object earlier in bitbake processingbitbake/ bitbake/ | +47 | 0 replies | |
| 4/4 | toasterui: handle ParseStarted eventsbitbake/ | +3 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [review-request][PATCH 0/4][v3] Capture failed build data earlier
v3:
Handle ParseStarted events which were causing a warning in the log.
v2:
Cleaned up some comments and log messages.
v1:
Toaster is unable to capture builds on the command line which fail before the BuildStarted event; and Toaster-triggered builds which fail before BuildStarted are recorded, but have no log available. This means that failed builds are represented inconsistently and without log data.
We can capture failed builds earlier to fix this as follows:
* Add an event to bitbake which fires just before each cooker command runs. This is necessary so that we can get at the command-line arguments passed to cooker before the command fails.
* Capture the buildTargets() command event (before the buildTargets() command runs) and use this as the marker for the start of the build.
* Modify toasterui so that the Build object is constructed when buildTargets() occurs, using its command-line target arguments to add Target objects to the build.
* If the BuildStarted event is fired, add additional data to the build about its layers etc. (so we effectively split construction of the Build object into two pieces).
Note that we can't use any earlier event (like ParseStarted) as the point to construct a Build object and its Targets, because buildTargets() is the first time we have access to the target list.
To test:
1. Start Toaster.
2. Create a project using master as the release.
3. Run a build for a non-existent target, such as "zzz".
4. Check that the build failure is captured, and that a log is available for it.
5. From the same prompt where you started Toaster, run a command-line build for the same non-existent target "zzz".
6. Check that the build is caught by Toaster, and that a log is available.
Changes since 42fdae7 (contrib/toaster-next) are ingit://git.yoctoproject.org/poky-contrib, elliot/toaster/failed_builds-8440
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=elliot/toaster/failed_builds-8440
Related bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8440
Elliot Smith (4):
command: fire CommandExecution event before a command runs
toaster: remove build_name from Build properties
toaster: create Build object earlier in bitbake processing
toasterui: handle ParseStarted events
bitbake/lib/bb/command.py | 7 ++++ bitbake/lib/bb/ui/buildinfohelper.py | 73 +++++++++++++++++------------------- bitbake/lib/bb/ui/knotty.py | 10 +++-- bitbake/lib/bb/ui/toasterui.py | 26 +++++++------ 4 files changed, 61 insertions(+), 55 deletions(-)
--
Elliot Smith
Software Engineer
Intel OTC
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.