| Summary: | Covered tasks with cache attempt "File not in cache" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Toaster | Reporter: | Belen Barros Pena <belen.barros.pena> | ||||||
| Component: | toaster | Assignee: | Alexandru Damian <alexandru.damian> | ||||||
| Status: | RESOLVED NOTABUG | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | Medium | CC: | alexandru.damian, belen.barros.pena, cristiana.voicu, jessica.zhang | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 1.6.2 | ||||||||
| Hardware: | All | ||||||||
| OS: | Multiple | ||||||||
| Whiteboard: | |||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||
| Attachments: |
|
||||||||
Created attachment 1954 [details]
database
I am not sure that this constraint is right. What happened here is: * the do_package task was looked up in sstate, and not found, hence the sstate_miss * the do_packagedata task of the same recipe was found in cache, and restored * since the do_packagedata was restored, the do_package is now covered (but it wasn't covered at the time of the sstate lookup) I feel that the task data accurately reflects this situation. Furthermore, for performance implications, I don't think it's productive to erase cached state after the task outcome changes. |
Created attachment 1953 [details] Covered tasks with File not in cache attempt I came across this when running a beaglebone build: covered tasks reporting a "File not in cache" cache attempt. This is not supposed to happen: only executed tasks can report a "File not in cache" attempt (Covered tasks are not executed tasks). I have attached a screenshot and the database.