When searching on +builds pages, we need more filtering options.

[Julian Edwards]

The various +builds pages do a substring search by default when filtering by package name. We should add a checkbox to signify that we want an exact match.

Also, we need to be able to filter by date built. Specify a date and a radio button list of:
 * Less than or equal to
 * Equal to
 * Greater than or equal to

Example URLs:
https://edge.launchpad.net/ubuntu/+builds
https://edge.launchpad.net/ubuntu/intrepid/+builds
https://edge.launchpad.net/ubuntu/intrepid/i386/+builds
https://edge.launchpad.net/ubuntu/intrepid/+source/pommed/+builds
https://edge.launchpad.net/~mozillateam/+archive/+builds

[Diogo Matsubara (matsubara)]

This is similar to bug 83616. Julian, aren't they dupes?

[Julian Edwards (julian-edwards)]

They look like dupes, although I prefer my description. This bug is also linked to the Build UI blueprint.

[Celso Providelo (cprov)]

The referred blueprint is obsolete for a long time, it's just grouping a bunch of mildly related bugs.

The immediate need we have, and are failing to delivery, is the ability to:

 1. Combine status, for instance (needsbuild, building) and (failedtobuid, chrootfail) without losing the ability to filter on each status individually. We could go to a discrete status selection like Answers filter but it would affect the possible order of the results.

 2. Regarding time filtering, I think the initial implementation can be less complex that what was originally suggested. We could start will border-filters, 'created_since_date' and 'built_until_date', which would suffice for slicing build records and Matthias want.

+1 for optional exact match on source names.

These changes are suitable and relevant for all callsites of the build lookup infrastructure and also the webservice. The only details that is not solved yet is how users will specific a collection of BuildStatus for filtering when calling getBuildRecords().

This is already a problem in other named-operation that support multiple arguments natively, but are restricted to single values in the webservice (IArchive.getPublishedSource, for instance).

Anyway, I think have almost everything we need to starting coding something in this area.

[Celso Providelo (cprov)]

In a later stage, as mentioned in bug #30612 and bug #83616, we may allow filtering on the people involved with build records. In practical terms this will be people involved with the *source* being built: creator, maintainer and sponsor.

But I don't really see an immediate use case for searching builds on this terms, maybe what people are looking for is an enhanced version of Person:+related-software (and children) which already present build status for sources related to the context user.

[Robert Collins (lifeless)]

On name filtering, if we make exact matches come first, we don't need a click-box. Thats a bit nicer, I think - and I think it is perhaps done already.

[Robert Collins (lifeless)]

This isn't really a bug in the sense of something not working right - I'm tagging it feature *and* dropping to low - but would be happy to have priority be high - in the sense that this would be a highish thing in the feature bucket.

[Matthias Klose (doko)]

this behavior now leads to timeouts in lp:~svammel when analyzing build records. Is there a workaround? If not, I think severity low is an exaggeration.

seen with lp:~mabac/svammel/fix-i386-timeout, calling

script -c "set -x; python file-failures.py -v --archive test-rebuild-20110329 --archive primary --bugtag='natty' --bugtag='ftbfs' --target-arch='i386' --reference-arch='' --importance=High --logfile=run-20110409.log"

[Robert Collins (lifeless)]

Any timeouts are a separate bug to this which is asking for filtering;
please ping me or another dev on IRC and give us the OOPS ID you get -
we can make sure there is a bug filed for the timeouts you are
experiencing.

[Mattias Backman (mabac)]

Hi,

I would like this fixed since it is a problem in lp:svammel as Matthias wrote earlier in this bug. I assume that this is due to the launchpad API behavior.

What I am trying to do is this using launchpadlib
  archive.getBuildRecords(build_state=state, source_name=source)
and I expect to get the build records for one package (package name in source) but I get the records for all the packages that contains the sub string source.

Thanks,

Mattias

[Robert Collins (lifeless)]

@mattias no the api is different; please file a new bug about your issue.

[Mattias Backman (mabac)]

Robert: thanks I have done that now.
https://bugs.launchpad.net/launchpadlib/+bug/757332