Created attachment 2956 [details] weird-build.png Steps to reproduce: I used a brand new sqlite database and removed the /tmp directory for good measure. Then I did the following: 1. Create a project in Toaster 2. Build something from that project (e.g. zlib) 3. Then switch to the command line and build something (e.g. dropbear) Instead of showing 2 builds, one for zlib inside the project you created in step 1, and a second build for dropbear inside the 'Command line builds' project, Toaster will show a single build with targets zlib and dropbear inside the project you created in step 1. See the screenshot attached to appreciate the weirdness :)
This happens if you start a command-line build while Toaster is still processing the Toaster-triggered build. buildinfohelper makes the assumption that only one build can be happening at a time, and holds a reference to a "current" build. All events which occur while the "current" build is open are attached to that build. However, even though a Toaster-triggered build may look "done", Toaster may still have database records to process and will hold the build object open until that's finished. In the meantime, a second build on the command line could be started, and its events get erroneously attached to the "current" build. We need to do a better job of detecting when the build is really done, and ensure that we attach events to the correct build as they occur. This could involve quite a lot of work, as we may have to have multiple build objects open at the same time in buildinfohelper, and a way to decide which of those builds an incoming event belongs to. I hypothesise that if you leave a decent gap between the end of the Toaster-triggered build and the command-line one, this shouldn't happen. If it does still happen under these circumstances, then the problem is even worse, as it means we're not closing builds correctly even when they're completely done and all the database operations for incoming events have been processed.
Again, I want to wait for the patches to fix bug 8440 to be merged before tackling this, as I may need to do some refactoring in buildinfohelper.
It looks like it may be worse than I thought initially, as I still get the two builds (Toaster-triggered and cli) merging with each other, even when there's a good gap between them.
After more testing, I have found that if I run cli builds, they are picked up and logged correctly by Toaster. If I then run Toaster-triggered builds, they are also picked up correctly. But if I then go back to cli builds (after the Toaster-triggered one), they get attached to the previous Toaster-triggered build...
(In reply to comment #4) > After more testing, I have found that if I run cli builds, they are picked > up and logged correctly by Toaster. If I then run Toaster-triggered builds, > they are also picked up correctly. But if I then go back to cli builds > (after the Toaster-triggered one), they get attached to the previous > Toaster-triggered build... Yes, this is exactly the behaviour I see as well.
It occurred to me that this might have something to do with BRBE being set, or not being set. I think Ed made some changes so that the TOASTER_BRBE variable is set on the bitbake server; this is then looked up in buildinfohelper to decide whether a BuildStarted event represents a new build or an old one, according to whether BRBE is set. If we are not unsetting TOASTER_BRBE at the end of a Toaster-triggered build, this might explain why command-line builds are attached to the last Toaster-triggered build.
I have a fix for this, but it depends on the patches for bug 8440: elliot/toaster/mixed_builds-9021 I'll submit the patch for review once those patches are in toaster-next.
Removed dependency, as I reworked the branch so it no longer depends on 8440. Submitted to toaster mailing list for review: https://lists.yoctoproject.org/pipermail/toaster/2016-February/003775.html
Merged into master: 1f7f07746629a55e4efd5f505e84eb6c66567115
Verified on 2.1_M2_rc3: 152914f2983c5d69001de1d46ce99547fa1e75fe