Currently, when you submit a new build, the hub creates a build task', which gets picked up by a builder. Off of that 'build task', a buildSRPMFromSCM subtask is created. Only after that subtask succeeds do we then create a top-level build object to record this work before proceeding to build all of the rpms and do any necessary tagging. That all works fine.
The problem is when buildSRPMFromSCM fails for some reason (user error, network failure, etc..). When it fails, we never create a top-level build object and therefore the postBuildStateChange callback never gets called (which cascades as silent failure to other systems that might be listening for that callback to know if the build fails).
This commit primarily moves the creation of that top-level build object earlier in the initial build task, to just before the buildSRPMFromSCM subtask is created.
Secondly, all the code surrounding the buildSRPMFromSCM task is indented to be inside a try: block, which will catch any failures there and propagate them to be recorded as a failure in the top-level build object.
Caveat emptor: I haven't tested this code, but it seems reasonable to me. Is there a reason that srpm creation was included in the build task but left out of the build object?
Currently, when you submit a new build, the hub creates a build task', which gets picked up by a builder. Off of that 'build task', a
buildSRPMFromSCMsubtask is created. Only after that subtask succeeds do we then create a top-levelbuildobject to record this work before proceeding to build all of the rpms and do any necessary tagging. That all works fine.The problem is when
buildSRPMFromSCMfails for some reason (user error, network failure, etc..). When it fails, we never create a top-level build object and therefore thepostBuildStateChangecallback never gets called (which cascades as silent failure to other systems that might be listening for that callback to know if the build fails).This commit primarily moves the creation of that top-level build object earlier in the initial build task, to just before the
buildSRPMFromSCMsubtask is created.Secondly, all the code surrounding the
buildSRPMFromSCMtask is indented to be inside atry:block, which will catch any failures there and propagate them to be recorded as a failure in the top-level build object.Caveat emptor: I haven't tested this code, but it seems reasonable to me. Is there a reason that srpm creation was included in the build task but left out of the build object?