| Summary: | Toaster thinks do_shared_workdir is a shared state task | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Toaster | Reporter: | Belen Barros Pena <belen.barros.pena> | ||||
| Component: | toaster | Assignee: | Ed Bartosh <eduard.bartosh> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | Libertad <libertad.gonzalez.de.la.cruz> | ||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | belen.barros.pena, jessica.zhang, richard.purdie, stanciux.mihail | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.2 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Belen Barros Pena
2016-01-06 12:04:02 UTC
The reason of this is that do_shared_workdir is a special task. It has correspondent setscene task and bitbake generates runQueueTaskSkipped event with the reason 'covered' for it. Toaster gets this event and considers task as covered and shows it in UI this way. I think my original comment was incorrect. do_shared_work *is* an sstate task however its designed never to actually generate sstate artefacts and would never appear in an sstate cache. This is in fact similar to more recently what Ed has been doing with image generation. I'm not sure what implications this has for toaster but it does seems we will have more of these "half functional" sstate tasks going forward for various reasons. This problem is connected to a Toaster design assumption: that all _setscene tasks have an sstate task associated with them. Toaster gathers the information from both the _setscene task and the sstate task, and presents all of it together as a single task. The rationale was that the split between _setscene and sstate tasks was a system model matter, i.e. something that BitBake does in order to get the job done. But what users really care about is the outcome of the BitBake 2-task process (i.e. that the task was not executed because a valid sstate object was found. This is the object, and it was retrieved from this location). Such outcome would be best presented in a single page, instead of split across 2 different pages, which means we needed to treat the 2 tasks as a single one. From Richard's and Ed's comments, our design assumption about the relationship between setscene and sstate tasks does not apply to do_shared_workdir, and more tasks like this might appear in future. If that's the case, we should probably reconsider the assumption we made. Since it is way out of scope at the moment, I will set this issue to resolved - won't fix. A note on reproducibility: the do_shared_workdir task is only shown as covered and sstate when reusing shared state with a clean tmp directory. So you will need to build linux-yocto, delete the tmp directory, then rebuild linux-yocto to reproduce the problem. |