New builds/changes should automatically pop up, like in the default buildbot views.

Size of bundle needs to be reduced.

https://travis-ci.org/macports/buildbot-macports-custom-views/jobs/552333524

    Unhandled rejection Error: original.line and original.column are not numbers -- you probably meant to omit the original mapping entirely and only map the generated position. If so, pass null for the original mapping instead of an object with empty or null values.

https://trac.macports.org/ticket/55978#Viewnr.3:Overviewofhistoryofbuildsofaparticularport

#6 (comment)

I believe it would be essential to provide and test the following setup:

• Just do the ports (leave out anything that doesn't have anything to do with port building; no base, no other strange jobs).
• When building a port do one single thing: calculate a random number between 1 and 100 and exit with 0 if that number is smaller than, say, 90, else exit with non-zero.
  • It can be a simple bash or python script or whatever.
  • Pick the easiest that gets the job done.
  • You may start with exit 0 without the random number generator.
  • You may even perform this step on the master without even calling the worker.
• In "port watcher" we should provide two different fields for manually triggering. One is "port list" and the other one is "port expression". If "port expression" is specified, run port info --index --line --name <expression> to extract the list of all ports and schedule all the ports you get as a result. Example: port info --index --line --name 'category:shells'. See also https://trac.macports.org/ticket/52989 and note that mpbb performs one sorting step for dependencies that's terribly slow. If you do end up using mpbb, make sure to avoid running that step (but maybe you can do it without mpbb anyway). We can help you with this part (I can definitely help, but it makes more sense to ask on the macports development mailing list).
  • No need to actually watch the changes from github, to avoid the extra complexity of figuring out which ports were changed. Force build functionality should be sufficient.
  • A potentially easier alternative would be to instead provide a field "number of builds" which would ask the API for the first N port names (or you can simply get the first N words from some dictionary), and pretend to build those. This would give you a complete independence of MacPorts, making it also much easier for the buildbot developers to test.
• Start testing by running a simple example like the above (specify category:shells as expression), but then try specifying all, and repeat that ten times.
• If the above is successful, try to connect a couple of workers from the same machine. The worker needs to have macports installed if you want to run port info, but it doesn't need root permissions, it doesn't need to install anything etc., and it won't burn the processor. (If you go with the second idea of just providing the number of ports and fetch the first N names from somewhere, you don't even need macports installed on the worker.)

The visual controls should ideally be tested on the results you get, which should by that time have a sufficient number of builds to get a good idea what the performance will be.

Builds for py-tensorflow and py-tensorflow_estimator are displayed on the same page.
http://ec2-3-17-139-39.us-east-2.compute.amazonaws.com/#/ports?id=py-tensorflow

• PortsList
• FilterBuilds
• ChangesList

• Add builds', workers' status badges (with result colors)
• Set up angularjs $location
• Fix styling
• [ ] Add sorting by different parameters in FilterBuilds.vue
• [ ] Add summary table to Change.vue