Series Explanation

Topcoder Mobile wants to improve their CICD pipeline process by adding an automated chrome devtools profiler execution. The goal is to capture all of the rich data and metrics that chrome devtools provides and generate a scorecard based on that data. With this scorecard added to the CICD pipeline, Topcoder Mobile will be able to identify things like bad code and memory leaks before the code gets merged into the main branch.

Input of this challenge

We have got an integrated Jenkins build process on Docker with the reference app from a previous challenge: https://www.topcoder.com/challenges/30062564/?type=develop

 

We have also got the extracted metrics from the profiling data based on a scorecard (provided in the forum) from these two private tasks:

https://www.topcoder.com/challenges/30062840/?type=develop&noncache=true&tab=details

https://www.topcoder.com/challenges/30062910/?type=develop&noncache=true&tab=details

 

Here is a sample of extracted metrics: https://raw.githubusercontent.com/topcoderinc/Headlessrefapp/_scorecard/profiling-data/profiles-2018_02_23T08_19_55_772Z.json

 

Where:

• total-routes: Number of all available routes.

• total-watchers: Number of watchers of each route.

• total-cache-size-mb: Total size of browser session storage, unit is MB.

• total-indexeddb-size-mb: Total size of IndexedDB storage, unit is MB.

• total-global-variables: Number of global variables.

• total-console-logs: Number of logs that is published to browser console.

• total-browser-objects: Number of browser objects.

• blocking-scripts: Number of blocking script for each route (per screen).

• total-sync-xhr: Number of sync XHRs per screen.

• total-async-xhr: Number of async (AJAX) XHRs per screen.

• total-memory-utilization-mb: Total memory utilization per screen, unit is MB.

• total-page-weight-mb: Page size per screen, unit is MB.

• total-cpu-utilization-percentage: Total percentage of CPU utilization per screen, unit is %.

Requirements of this challenge

The goal of this challenge is to generate an HTML report page for the metrics data visualization.

 

The layout of the HTML report page should be organized similar to how lighthouse looks, here is a sample layout.

 

 

The HTML report page should contain two sections:

(1) Left section (in the red rectangle): it lists all the routes in the profiling data. Each item should be clickable to navigate the right section to show its corresponding metrics. This section should be vertically scrollable.

(2) Right section (in the green rectangle): it lists the metrics of each route. This section should be vertically scrollable too.

 

Note that the HTML report page should be responsive - if a route contains too many metrics that cannot be shown in one row (see the area in the yellow rectangle), these metrics should be wrapped into multiple rows in their own section.

The data with the circle chart should be colored, which represents the “healthiness” of the data. The “healthiness” of the data can be calculated by the value of the data V and the threshold of the metric T. We introduced three colors to represent it.
(1) Green (#2b882f): when V <= 0.8T

(2) Yellow (#ffab00): when 0.8T < V <= T

(3) Red (#df332f): when V > T

 

Note that you should provide a config file to set the threshold T for each metric, as well as the ratio 0.8. Here is an example of the config file

{

     “healthyRatio”: 0.8,

 

     "total-watchers": 0,

     "total-cache-size-mb": 5,

     "total-indexeddb-size-mb": 30,

     "total-global-variables": 25,

     "total-console-logs": 0,

     "total-browser-objects": 100000,

     "blocking-scripts": 0,

     "total-sync-xhr": 5,

     "total-async-xhr": 5,

     "total-memory-utilization-mb": 200,

     "total-page-weight-mb": 200,

     "total-cpu-utilization-percentage": 25

}

Notes

1. The code repository is the https://github.com/topcoderinc/Headlessrefapp.git, “_scorecard” branch, see https://github.com/topcoderinc/Headlessrefapp/tree/_scorecard

2. lighthouse is just for the layout reference of the HTML report, you don’t have to use it to generate the HTML. You can use any charting library you like, such as chartjs, c3.js etc. But you should provide an explanation on why you chose the charting library in your README.md.

3. The generated HTML report page should be put in a “scorecard-reports” directory of the repository root. Each HTML report file name should be “scorecard-reports-<datetime>.html”. For example, for the profiling metrics “profiles-2018_02_23T08_19_55_772Z.json”, the HTML report file name is “scorecard-reports-2018_02_23T08_19_55_772Z.html”.

4. The layout of HTML report pages is not strictly limited, you can freely design the layout as long as it meets the requirements mentioned above and looks good.

5. You are required to integrate the step of generating the HTML report to the existing Jenkins process, so that the generation could be processed automatically. Update the existing Jenkinsfile in the repository here: https://github.com/topcoderinc/Headlessrefapp/blob/_scorecard/Jenkinsfile

 

Final Submission Guidelines

(1)  A git patch against the commit hash 4f3131a80e141621b1f3d20a814d270c60c90b0d of the _scorecard branch of https://github.com/topcoderinc/Headlessrefapp.git, it should include

• The updated readme.md that includes the introduction and deployment guide of scorecard visualization.

• The code to generate the HTML report.

• The updated Jenkinsfile

• A generated HTML report. Don’t include too many HTML reports of the profiling-metrics JSON in the patch, only one is enough.

(2)  A separate README.md with all steps to setup the code for generating HTML report, and an explanation of the choice of charting library. Documentation needs to be comprehensive enough so someone who has never done this before is able to set it up on another application / jenkins environment.

(3)  Video demonstrating the process of generating the HTML report and the result of the report (feel free to annotate with text)