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

Bug #231862 reported by Julian Edwards on 2008-05-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

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:

Changed in soyuz:
assignee: nobody → al-maisan
importance: Undecided → High
milestone: none → 1.2.6
status: New → Confirmed
description: updated
Celso Providelo (cprov) on 2008-06-10
Changed in soyuz:
assignee: al-maisan → nobody
milestone: 1.2.6 → none
Diogo Matsubara (matsubara) wrote :

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

Julian Edwards (julian-edwards) wrote :

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

Celso Providelo (cprov) wrote :

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) wrote :

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) wrote :

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.

Changed in soyuz:
importance: High → Low
tags: added: feature
Robert Collins (lifeless) wrote :

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) wrote :

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"

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

Mattias Backman (mabac) wrote :


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.



Robert Collins (lifeless) wrote :

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

Mattias Backman (mabac) wrote :

Robert: thanks I have done that now.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints