9916 2016-07-12 16:13:24 +0000 Show git clone progress in most recent builds area 2017-07-12 15:26:53 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster 2.3 x86 Multiple RESOLVED FIXED Medium enhancement 2.4 M2 9631 1 elliot.smith david.reyna belen.barros.pena brian.avery david.reyna jessica.zhang stanciux.mihail libertad.gonzalez.de.la.cruz --- --- No (bug/feature does not impact docs) oldest_to_newest 63851 0 elliot.smith 2016-07-12 16:13:24 +0000 At the moment, if a project has a lot of additional layers, the build may appear to hang while those layers are checked out. Add another progress bar to the most recent builds area during the time while the git cloning is going on. Suggest that we wait until after Toaster has been refactored to use the bitbake fetcher for cloning git repos. Also suggest that we put data about git cloning into the database, attached to the BuildRequest (we can't put this data onto the build, as the git clone happens before we have a Build object). 68369 1 david.reyna 2016-11-16 16:15:09 +0000 Want to keep as one story, but break up commits into front end and backend. 74442 2 david.reyna 2017-06-21 21:40:29 +0000 We actually do have the build object while the cloning is performed. If we did not there would be any progress bar at all, since in the current implementation all progress information is shared with the GUI via the build record. FYI, this is actually a long term problem in that Toaster is inappropriately using the database as an RPC, and every incremental progress update for parsing and tasks causes a record update. This results in massive database transactions for purely transient data. Brian had looked at a long term solution using perhaps Rabbit (message queues) and Celery (multi-threading python support). 74958 3 david.reyna 2017-07-12 15:26:53 +0000 commit 43aaa802c35ecc9d972f3b9adcd060033de1d9de Removing dependency on Bug 9918, since it does not block this implementation.