Introduce pagination for Build Monitor

[janfaracik]

Hopefully addresses #1214

This PR introduces pagination for Build Monitor, allowing essentially an infinite number of jobs in your monitors.

I'd love to get some feedback on this, thanks!

@timja

Testing done

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[CJCombrink]

This looks promising thanks.

Would it be possible to have an option to control either pagination or scroll bars or will it always paginate on overflow?

Sorry I can't read ts/js/java fluently

[janfaracik]

Would it be possible to have an option to control either pagination or scroll bars or will it always paginate on overflow?

It would be possible yeah, just wondering what scenario you have where you'd rather it scroll rather than paginate?

[timja]

Generally this looks a lot better and I'd suggest shipping it to get it to users to incrementally enhance it

---

In progress parallel builds are still very broken looking with stage names:

You can test with:
timja-org/junit-attachments-test#10

---

I wonder whether it should handle it better if you increase columns:

Should it decrease font size or reduce the information if there's not enough space?

[david-jennings]

With the widgets roughly square the page looks nice but now I have a lot less information on one page. I have view with about two hundred once-a-week jobs (probably not the norm) and it's good to see the build state of as many as possible in a glance.

To partly support this I set the text size to 0.6 and columns to 7.

It'd be nice if the vertical spacing collapsed to the minimum that supported the underlying text (perhaps as a default-off option, since others might prefer the more spacious layout).

[eliasbalasis]

I agree with @david-jennings and have pointed out the same concerns at #1214 (comment)

The spacing is not flexible anymore, limiting the information displayed particularly when examining large number of jobs, which is not necessarily uncommon.

Besides making the spacing like it used to be, I would also suggest making pagination optional and retain scrolling as per original design.

I am suspecting the origin of all problems is #1108 but I could be wrong.

[FriedrichKiesel]

Keeping the scrolling feature would be very important to us. We have many (like 100) jobs in a singel view and scrolling ist the only efficient option to look at them all.
Pagination is a good start, but clicking trough 10 pages just to check what you could do in a few seconds with scrolling doesn't feel like an improvement at all.

For now, I reverted to the old version that still had scrolling.

[eliasbalasis]

Good point @FriedrichKiesel

I am expecting this to be 1.14-985.v7b_f37b_3d0b_f5

Is my understanding correct ?

[FriedrichKiesel]

I am expecting this to be 1.14-985.v7b_f37b_3d0b_f5

Yes, that is the version we are using. For now this works, but with the old design.

[bretrzaun]

The new pagination feature breaks our usage of the Build Monitor Plugin as a build wallboard:
Seeing all builds on one page without the need of any interaction.

Please make the pagination to be disabled.

[janfaracik]

The new pagination feature breaks our usage of the Build Monitor Plugin as a build wallboard: Seeing all builds on one page without the need of any interaction.

Please make the pagination to be disabled.

Is it possible to increase the number of columns to match the number of jobs you have?

[eliasbalasis]

I am afraid I have tried, it all gets very messy and difficult to work when the number of jobs is large.

[bretrzaun]

I am afraid I have tried, it all gets very messy and difficult to work when the number of jobs is large.

Same here!