Bug 6095

Summary: Retrieve full build information independently of task execution
Product: [Build System, Metadata & Runtime] Toaster Reporter: Belen Barros Pena <belen.barros.pena>
Component: toasterAssignee: David Reyna <david.reyna>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: Medium CC: alexandru.damian, belen.barros.pena, cristiana.voicu, dave.lerner, david.reyna
Version: unspecified   
Target Milestone: Future   
Hardware: All   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Belen Barros Pena 2014-04-01 14:35:05 UTC 
Currently, if do_package does not execute, Toaster does not collect built package information. If do_rootfs does not execute, Toaster does not collect image files and license manifest information. For some history about this issue, see bug 5269

Toaster should collect all information about a build independently of task execution. 

This is RP's suggested solution:

how about when toaster sees package or image information, it logs it into the database against the sstate checksum for that task. If a build then reuses something with a sstate checksum we know about, we can pull that data back out the database and display it?
Comment 1 Dave Lerner 2014-04-08 19:28:48 UTC 
Adding the sstate checksum to the database seems reasonable as I also suggested a few weeks ago, use the database just as sstate-cache is used to cache information. However, this technique fails if sstate cache is populated when toaster is not running.
Comment 2 Alexandru Damian 2015-04-28 14:43:53 UTC 
case A). Toaster already stores sstate checksums for tasks, so we only need to modify the interface to bring in data from previous executed task with the same checksum.

case B). Toaster doesn't have the previously task with the same sstate id. The data is not generated at all by the build system, so it is impossible to gather it unless we force re-execution of tasks, with the associated time and performance penalty. I recommend that case B should be Will Not Be Fixed.

This bug remains open to track implementation of case A. 
Assigning to Dave, as developer of the original task pages.