Created attachment 2454 [details] Most built targets not showing targets for failed build requests Toaster does not differentiate between builds and build requests: the difference is an implementation issue of no interest to users. As far as Toaster users are concerned, builds include: * Successful builds * Failed builds * Failed build requests (that look like and behave as failed builds) Based on the above, the 'Most built targets' section in the project page should apply its logic to targets of any build (successful or failed), and to targets of any failed build requests. Right now, as you can see from the attached screenshot, it only applies to builds.
Since the previous commit for the related issue added the code: freqtargets += map(lambda x: x.target, reduce(lambda x, y: x + y, map(lambda x: list(x.brtarget_set.all()), BuildRequest.objects.filter(project = prj, state = BuildRequest.REQ_FAILED)))) and my test cases that build an invalid target, bogus-target instead of core-image-minimal put that bogus-target to the top of the Most Frequently Built list after a recent pull/rebase, then either: 1) BuildRequest.REQ_FAILED looks like but does not actually include the case you are noting in your attachment, or 2) building a non-existent target does not generate the same kind of failure that you are noting in your attachment, or 3) or (like me wondering why it was broken) you didn't do a page refresh after the builds failed which was permitted IIRC in the previous defect and spec. If (1) and (2) are correct, that is, building a target like 'core-image-fail-this-one' is a failed build but not a 'failed build request', then how would I generate a failed build request?
Verified that the database field BuildRequest.state is failed, implying that the build request failed, for the bogus targets. See below: sqlite> select * from bldcontrol_buildrequest as R, bldcontrol_brtarget as T where R.id = T.req_id and R.state = 4; build_id = updated = 2015-03-13 21:54:08.942266 environment_id = 1 created = 2015-03-13 21:53:42.178395 state = 4 project_id = 1 id = 5 id = 5 req_id = 5 target = bogus-target task = ... build_id = updated = 2015-04-06 20:59:42.169019 environment_id = 1 created = 2015-04-06 20:59:16.895313 state = 4 project_id = 1 id = 12 id = 13 req_id = 12 target = bogus-target task = bogus-target is at the top of the most built target list and is always a failed request bldcontrol_buildrequest.state = 4 which is FAILED request.
> 3) or (like me wondering why it was broken) you didn't do a page refresh > after the builds failed which was permitted IIRC in the previous defect and > spec. It turns out to be 3) Sorry about that. Marking as resolved, works for me.
Verified on master: 4a711028c709d4bb1421e1637ae3fb0ac404fb45