Well, the algorithm for the buildhistory widget on the job page is, put simply; list all queued builds then start listing the history (that would include currently running builds iirc). So if only the history part of the list was paginated, the first page iiuc would have the queue plus X builds and page 2 would have X builds making the height of the witget change between page flips. If the first page only listed "queue length - X" builds how would it handle transitions between pages if a build left the queue and started building between page flips?
And what if you have 100s/1000s of builds of that job in the queue? I'm not saying don't do it, something needs to be done about that widget, I'm rather lifting some concerns :) /B On Mon, Jan 26, 2015 at 9:25 AM, Tom Fennelly <[email protected]> wrote: > Hi Bobby. > > What do you mean when you talk about moving it out into a separate widget? > Move which parts out? Are you saying have 2 widgets, one for > in-queue/running builds and one for completed builds? > > Perhaps I don't know all the use case but I was thinking (as I said in the > original email) that once you move away from the top/head of the build > history, then the widget stops tracking the top/head of the build history > i.e. doesn't track at all or just tracks the "window" in the build history > that they are currently looking at. If you want to track the top/head > again, just "page" back to the top (or press the "Top") button. Seems to me > like it's not really humanly possible to look at 100s/1000s of builds all > at one time anyway. > > On Friday, January 23, 2015 at 6:27:24 PM UTC, Robert Sandell wrote: >> >> What about the "in queue" part of the widget? >> I vote for moving it out into a separate widget otherwise tha pagination >> could get tricky if a build has been added or removed from the queue >> between page requests. >> >> /B >> >> On Fri, Jan 23, 2015 at 5:31 PM, Jesse Glick <[email protected]> >> wrote: >> >>> On Fri, Jan 23, 2015 at 11:11 AM, [email protected] <[email protected]> >>> wrote: >>> > I know its not exactly the same thing, but maybe this could also >>> create some ideas on how to solve an issue in the timeline widget: >>> JENKINS-22008 >>> >>> I think the implementation work would be mostly unrelated. >>> JENKINS-22008 “just” needs someone to sit down and wrestle with the >>> JavaScript a little bit to use a lazy iterator. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/jenkinsci-dev/CANfRfr3BC%2By2hMAuyC41jf7P5UBfCsf0% >>> 2BB0LYuDHunrTnRZ9rw%40mail.gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Robert Sandell >> *Software Engineer* >> *CloudBees Inc.* >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/0f084c3a-f4a9-4fd1-ad22-578697037f9a%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/0f084c3a-f4a9-4fd1-ad22-578697037f9a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2QV3k6PwJkND8Q8vTpROMqNrHau6OJ-s5QJ3h48emUkA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
