Summary
It would be useful to have the ability to view both the pattern of machine usage over time by platform, and also an analysis of this data (e.g. peak capacity vs peak usage, or total per-day usage vs total per-day capacity).

Reasoning
This data, if correctly analysed, would give us an at-a-glance answer to the following questions:

• How many machines do we need per platform, vs how many we have (and pay for)?
  Pros: Saves us money.
• How many builds can we run across all our build machines by platform, per day?
  Pros: Lets us approximate the number of new builds we can add, e.g. fast debug, Amber, etc.
• How much spare test time do we have?
  Pros: Minimises the risk that a new test will exceed the amount of machine time we have each day.
• Which platforms have the most spare capacity?
  Pros: Lets us offer nightly build slots to communities, even if we don't have terribly accurate estimates on the amount of time it takes them to build.

Details

The initial vision is of a graph showing available throughput vs used throughput over time, with controls beneath and a side-bar showing analytics.

Optional extras

• A feature that lets us add multiple hypothetical build and test jobs to each platform, and displays warnings if the addition of these would exceed available machine time.
• A feature that breaks down machine throughput by cost, and displays the price of adding new builds.

Notes
Some of this may overlap with the Nagios issue. To review when that issue is complete.

https://github.com/AdoptOpenJDK/openjdk-dashboard-v2/runs/759987620?check_suite_focus=true

Failing on the packaging step which is odd as underlying dependencies did not change

The website dash.adoptopenjdk.net is currently not responding.

It appears that the Dependabot has made a breaking change to the CNAME file on the gh-pages branch, changing it from dash.adoptopenjdk.net to dash-v2.adoptopenjdk.net.

Note that the master branch still has dash-v2.adoptopenjdk.net.

When comparing the trends in OpenJ9 vs Hotspot the differences in absolute values squashes the trends in OpenJ9 into a (more or less) flat line. It would be helpful to see a normalized line graph (probably to the maximum point on each line) to show the trends side by side in a more comparable way.

We're looking to increase the v2 dashboard's functionality to be able to show two new sets of data.

1. A bar chart view of total downloads per month, for both HotSpot and OpenJ9. Eg:

2. A trend view of HotSpot and OpenJ9's total download figures across a time-period. Eg:

For this we would need some new endpoints from the v3 api (AdoptOpenJDK/openjdk-api-v3#129). Most of the front end work for this seems simple enough as there is already lots of useful framework.

The newly added download trends chart could perhaps be better implemented using RangeSelectors from Highchart

With the completion of AdoptOpenJDK/openjdk-api-v3#44, we can use the API to pull the historical download count and compare operating systems, sources, versions and dates. A feature should be added that will allow users to view historical download trends across various fields. This should be possible using reactjs libraries (https://react-dashboard.cube.dev/, https://react-bootstrap.github.io/, etc)

Deliverables

• Await conversion of website to react.js
• Show download stats over a specified amount of time
• Graph download trends across jdk versions, architectures and sources
• Ensure the stability of the vanilla js website is not upset by the inclusion of react elements

antd ^3.26.18 → ^4.18.7
express ^4.17.1 → ^4.17.2
highcharts ^9.0.0 → ^9.3.3
highcharts-react-official ^2.2.2 → ^3.1.0
http-proxy-middleware ^0.19.2 → ^2.0.3
moment ^2.26.0 → ^2.29.1
react ^16.13.1 → ^17.0.2
react-dom ^16.13.1 → ^17.0.2
react-router ^5.2.0 → ^6.2.1
react-router-dom ^5.2.0 → ^6.2.1
@babel/core ^7.10.2 → ^7.17.2
@babel/plugin-proposal-class-properties ^7.10.1 → ^7.16.7

[email protected] start
node server.js

🚨 Cannot read property 'length' of undefined
at lineCounter (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/utils/lineCounter.js:3:30)
at JSPackager.writeModule (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/packagers/JSPackager.js:127:60)
at async JSPackager.addAsset (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/packagers/JSPackager.js:88:5)
at async Bundle._addDeps (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/Bundle.js:250:5)
at async Bundle._package (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/Bundle.js:219:7)
at async Promise.all (index 0)
at async Bundle.package (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/Bundle.js:202:5)
at async Promise.all (index 2)
at async Bundle.package (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/Bundle.js:202:5)
at async Bundler.bundle (/Users/karianna/Documents/workspace/adoptopenjdk/openjdk-dashboard-v2/node_modules/parcel-bundler/src/Bundler.js:325:27)

Whilst working on AdoptOpenJDK/openjdk-api-v3#306 I spotted that the old V2 dashboard is still running but appears to be broken.

One option is to look at fixing it but maybe a better option would be to redirect to the latest dashboard based on the V3 API.

When requesting to view the trends from the AdoptOpenJDK dashboard, we cannot do it, and the message is "Something went wrong."

The newly added download trends chart has a filter selection with hardcoded JDK versions.
We can do a simple api query of available versions, and render that set of version filters?