Ticket #2213 (closed defect: wontfix)
console webpage doesn't always show revisions when using branch=*
| Reported by: | JocelynJ | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.8.+ |
| Version: | 0.8.5 | Keywords: | web |
| Cc: |
Description
Hi,
I'm using a buildbot master that polls a SVN repository, with a busy trunk, and a quiet branch. I want to be able to use console.py?branch=branches/test so that only revisions and builds relevant to the branch are shown.
What I can see is that, if there are too many revisions on trunk since last commit on the branch, the console doesn't show any revisions - which makes it hard to directly check if the branch is OK or not.
According to the code in 0.8.5 of buildbot/status/web/console.py, this is because getAllChanges() only gets up to 25 revisions, and the filtering by branch is done a little later in stripRevisions(). I think these two functions should be merged, so that it is more similar to getRecentSourcestamps() in grid.py.
Is the current behavior expected ?
Is there any reason to split getAllChanges() and stripRevisions() in two different functions ?
Thanks, Jocelyn
Attachments
Change History
comment:2 Changed 15 months ago by dustin
- Type changed from undecided to defect
- Milestone changed from undecided to 0.8.+
comment:3 Changed 15 months ago by JocelynJ
I understand the issue: I handle an instance that has a lot of revisions, and the console interface can be slow sometime. I will see if I can efficiently merge these two functions.
Changed 15 months ago by JocelynJ
-
attachment
0001-Add-optional-branch-argument-to-function-getRecentCh.patch
added
Add optional branch argument to function getRecentChanges()
Changed 15 months ago by JocelynJ
-
attachment
0002-Move-logic-to-take-only-a-specific-branch-in-console.patch
added
Move logic to take only a specific branch in console to database
comment:4 Changed 15 months ago by JocelynJ
I just did a quick trial, by moving the branch check to direct database queries. The patches are still rough, but do you agree with this solution ?
comment:5 Changed 15 months ago by tom.prince
This looks like a reasonable approach. Thanks. If you are moving the filtering down to the db, why not move all the filtering there? Some tests will be needed for the db-connector changes. (Unfortunately, there are almost no tests for the web interface yet)
![[Buildbot Logo]](/chrome/site/header-text-transparent.png)
All of these status-getting functions are a compromise between efficiency and getting the required data. On larger installs, fetching hundreds or thousands of changes on every page fetch can easily bring a master to its knees.
If you can propose a change that will not appreciably diminish performance, I'm all ears.