[discussion] Considering relevant attributes from Graal for Visualization

[inishchith]

WRT Integration Task: Graal with ELK

@valeriocos @jgbarah @aswanipranjal: This issue thread is for discussion related to what attributes from the results produced by Graal are relevant and should be considered for visualization and creation of dashboards.

---

Note:

1. Currently, the integration task is conducted for CoCom backend only, so the attributes in consideration are -

analysis = [
...
 {
  "ccn": 19,
  "avg_ccn": 2.111111111111111,
  "avg_loc": 9.11111111111111,
  "avg_tokens": 64,
  "num_funs": 9,
  "loc": 129,
  "tokens": 786,
  "ext": "py",
  "blanks": 48,
  "comments": 63,
  "file_path": "graal/codecomplexity.py"
}
...
]

[inishchith]

@valeriocos @jgbarah @aswanipranjal As per our last meeting ( on Friday, 7th June ).
We had thought to visualize changes over some of the above attributes over a (configurable) amount of time. I'd be working on it this week ( as discussed ) and ask doubts/questions here ( if any)

Any thoughts or suggestions on it?

Thanks!

[inishchith]

[ As we can see the above-referenced issues ]

[analyzer] Fix results for deleted files: chaoss/grimoirelab-graal#35

There were some issues/redundancy in the results retrieved from the (CoCom) Backend, which can be fixed via this issue.

[cocom] Evaluating results with repository level analysis: chaoss/grimoirelab-graal#36

We had discussed of visualizing some of the attributes for a given repository on a given point of time. There could be two approaches:

• The current implementation of Graal's CoCom Backend produces results over the files affected for a given commit, Hence, in order to produce the visualization, we have to pick the last updated values of all the files and perform sum total of the particular attribute, which would be a bit complex to implement in Kibana. ( though we've been discussing how to implement this efficiently ).
• Alter the current implementation of Graal's CoCom Backend to have an option to produce results at the repository level, which would make it easier to implement the visualization along with the evolution of the attribute (using serial diff). The above issue is for the evaluation of this idea ( which will also be discussed in this week's meeting. (Friday)

@valeriocos Please let me know in case I missed something out. Thanks :)

[inishchith]

@valeriocos @aswanipranjal @jgbarah

I've worked on the repository level analysis and could produce the following results ( which can be
further improved after some discussion )

Repository: chaoss/grimoirelab-perceval

---

[ Total Lines of Code at a given point of time ( here per month ) ]

---

[ Total Code Complexity at a given point of time ( here per month ) ]

[inishchith]

Using Kibana's TimeLion + Analysis data (Repository Level)

[ Code Complexity per week ]

---

[ Code Complexity v/s Lines of Code per week ]

[valeriocos]

Thank you @inishchith , did you try to use timelion with the non repository-level data?

[inishchith]

@valeriocos Sorry for the delayed response.
The idea was to sum the values of the latest data. Yes, I did try it, but couldn't get the configuration correctly. I'm still looking up for related examples

[inishchith]

In reference to the repository-level analysis using lizard. ( REF. chaoss/grimoirelab-graal#38 (comment))

Repository: chaoss/grimoirelab-perceval

[ Total Lines of Code after latest commit]

---

[ Total Code Complexity after latest commit ]

---

[ Most Complex files after latest commit ]

(issue with the above is that the latest commit analysis contains results of all the files. hence the changes cannot be tracked down to which commit made it more complex ( evolution ) )

[inishchith]

closing in reference #11