Thanks - send to bitbake-devel and applied to toaster-next
On 13/09/16 14:21, Ed Bartosh wrote:
There is no need to lock build environment before changing build status as this operation is very fast. However, there is a need to unlock it after changing build status. Explicitly unlocked BuildEnvironment after build reaches final status SUCCEEDED, FAILED or CANCELLED. This should allow runbuilds process to pickup next build faster. Signed-off-by: Ed Bartosh <ed.bart...@linux.intel.com> --- bitbake/lib/bb/ui/buildinfohelper.py | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/bitbake/lib/bb/ui/buildinfohelper.py b/bitbake/lib/bb/ui/buildinfohelper.py index c93ee94..2246960 100644 --- a/bitbake/lib/bb/ui/buildinfohelper.py +++ b/bitbake/lib/bb/ui/buildinfohelper.py @@ -1524,9 +1524,7 @@ class BuildInfoHelper(object): returnbr_id, be_id = self.brbe.split(":")- be = BuildEnvironment.objects.get(pk = be_id) - be.lock = BuildEnvironment.LOCK_LOCK - be.save() + br = BuildRequest.objects.get(pk = br_id)# if we're 'done' because we got cancelled update the build outcome@@ -1543,6 +1541,10 @@ class BuildInfoHelper(object): else: br.state = BuildRequest.REQ_FAILED br.save() + + be = BuildEnvironment.objects.get(pk = be_id) + be.lock = BuildEnvironment.LOCK_FREE + be.save() signal_runbuilds()def store_log_error(self, text):
-- _______________________________________________ toaster mailing list toaster@yoctoproject.org https://lists.yoctoproject.org/listinfo/toaster
