adessose / coderadar Goto Github PK

Continuous code analysis server.

License: MIT License

Java 69.84% CSS 2.47% JavaScript 0.09% TypeScript 18.68% HTML 3.55% Shell 3.39% Perl 0.79% Dockerfile 0.01% Batchfile 0.03% SCSS 1.15%

coderadar's Introduction

coderadar

coderadar aims to be a continuous source code analysis tool that automatically runs code analyzers on your version control system that provide you with the metrics that are most important to you and your team. coderadar provides per-commit code metrics and even allows viewing the history of code metrics in legacy projects.

Goals of coderadar

coderadar is a tool for architecture reviews. It visualizes the architecture within a code base and helps to evaluate actions to improve the architecture.
coderadar is a tool for code quality reviews. It visualizes metrics and hotspots within the codebase and helps to evaluate actions to improve the code quality.
coderadar is a tool for continuous retrospection. It provides dashboards and tools to facilitate regular retrospectives with the goal to improve quality over time.
coderadar is a tool for historical analysis. It provides metrics for selected time frames to make it easy to compare changes in quality over time.
coderadar is a tool for gamification. It provides mechanisms to gamify code quality and to improve motivation for developers to produce quality code.

Documentation

Want to contribute?

See the contribution guide.

coderadar's People

Contributors

Stargazers

Watchers

coderadar's Issues

Diff File Metric Values

Diff selected metrics of a selected file between two selected commits.

Add a message to Findings

Findings should be able to store a localized message to be displayed in the code review where findings are marked.

List metric descriptions

Currently, the REST API works with string-based metric IDs to identify metrics.

It should be possible to get the descriptions to a set of metric IDs. This way, a client can query the description for one or more metrics IDs at a time to display them to the user.

This requires a change in the Analyzer API so that each analyzer is able to provide a description to each metric it supports.

Diff of module metric values

It should be possible to get a list of metric value diffs for a selected set of metrics and two selected commits aggregated on a certain module.

Depends on #42.

Progress monitoring

The annotator should support progress monitoring so that the user can be informed of the progress of an annotation process.

dockerize coderadar

Add a Dockerfile and a build configuration to build a coderadar Docker container.

I'll add a PR to implement this.

re-scan with selected analyzers only

Re-scanning the metrics of a project can be done by setting a new AnalyzerStrategy (see http://thombergs.github.io/coderadar/1.0.0-SNAPSHOT/docs/restapi.html#_setting_a_project_s_analyzing_strategy)

However, before re-scanning, ALL metric values of the projects are being deleted.

It would be nice to be able to delete only the metrics of a selected set of analyzers so that it is possible to add a new analyzer at some later time and re-scan all previous commits with this new analyzer only.

add build server

Support credentials when cloning a remote repository

You should be able to specify credentials when cloning a remote repository, so that the annotator works with private repositories.

List Files

List all files that were modified in a selected commit.
List all files that exist in a selected commit.

Diff Commit Metric Values

Display the diff between selected metrics in two selected commits.

configure source files into modules

It would be nice to aggregate metrics into modules additionally to single files.

Idea: add a REST endpoint to configure module prefixes. These prefixes are the path of the module from the root of the VCS repository.

For example, in the coderadar VCS a module prefix would be "server/coderadar-webapp". The server can then aggregate metrics for a module by adding all metrics of files whose paths start with this prefix.

Metric Contributions ("highscores")

A "highscore" list of committers and their contribution to a selected metric or quality profile.

The highscore table contains these columns:

place in the highscore table (starting with 1)
name of the committer
value of a selected metric

The user can do the following actions:

select a metric from a dropdown to be displayed in the highscore list. The highscore list is then reloaded an re-sorted accoring to the new metric.
select the date range to consider in the highscore counting

View Findings in a File

Show the content of a file with all metric findings marked.

The file should be syntax highlighted.

Route the writing of annotations through the annotation-api

Currently, the annotator accesses the git repository directly to add notes to a commit. This should be routed through the annotation-api component.

Diff commit quality profile ratings

It should be possible to query for a diff in quality profile ratings between two commits.

Returned values:

delta complianceRating
delta violationRating

(see #33 for explanation of those values)

List total commit metrics values instead of only those of modified files

The result of "GET /projects/1/metricvalues/commits" when queried for certain metrics should contain the metric values over all files in the selected commit, not only the files that were modified with the commit.

PMD analyzer

Implement an analyzer that performs a PMD analysis.

Commit History

A list of all commits, visualized as a tree of commit nodes.

For each commit the following data is displayed:

commit message
committer
commit date
commit hash
number of findings of a seleted metric within this commit

User input fields:

date range picker: show only the commits within the specified date range
metric dropdown to select the metric to be displayed for each commit
button to load the next X commits (by default only 20 or so should be displayed)

List File Metric Values

List selected metric values for a set of selected files in a selected commit.

remove option to not accept binary files from AnalyzerFilter

Remove the method acceptBinary() from AnalyzerFileFilter, since binary files can be ignored using FilePatterns.

Load file content

Implement a REST endpoint to load the content of a specified file in a specified commit.

Chart metric values

Display a line chart that shows the development of selected metrics over a selected time span.

Jacoco report analyzer

Implement an analyzer that reads a jacoco report to create test coverage metrics.

Depends on #36.

Push metrics to remote repository

The metrics are added to the local git repository as git notes to each commit. The annotator should have an option to push these notes to the remote repository for later use.

Generic Metric Chart

Display a line chart displaying one or more metrics over a selected date range for a selected module. The line chart should be responsive so that it reacts directly to user input.

Input:

user can select the module whose metrics to show
user can select any existing metric to add to the chart
user can remove any metric from the chart
user can select the date range to display

Output:

a line chart displaying the metric values over time
for each metric, display the difference between start date and end date prominently

Implementation hints:

the metric chart should be built as a component so that it can later be configured as a widget in a dashboard

Give analyzers the option to ignore binary files

Analyzers should be able to ignore binary files.

Findbugs report analyzer

Implement an analyzer that reads a findbugs report to integrate findbugs metrics into coderadar.

Depends on #36.

support remote SVN repositories

Currently, only GIT repositories are supported to be cloned locally and then analyzed.

SVN repositories should be supported also.

Note that a remote SVN repository must be cloned into a local git repository via "git svn clone".

List total quality profile rating instead of only that of modified files

The result of "GET /projects/1/metricvalues/commits" when queried for a certain quality profile should contain the following values:

total complianceRating: metric count with metricType COMPLIANCE (in respect to the selected quality profile) over all files in the selected commit
total violationRating: metric count with metricType VIOLATION (in respect to the selected quality profile) over all files in the selected commit

Currently, the values complianceRating and violationRating only contain the metric count of the files that were modified with the commit.

IDE integration

Develop a plugin for IDEs like IntelliJ and Eclipse that performs the same analysis as coderadar.

Clone only latest x commits

The annotator should have an option to clone only a specified number of the latest commits instead of always cloning ALL commits to the local repository.

Let analyzers implement a destroy() method

...so that they can configure themselves in configure() and release any resources in destroy().

Allow configuration of exclude list

Allow configuration of an exclude list. These files will NOT be passed to any analyzer.

Allow grouping of metrics to custom categories

For example, I would want to group some findbugs violations to a "MAJOR" metric and some to a "MINOR" metric. This grouping should be made AFTER analysis, so that it can be changed without running the analysis again.

assign findings to a user to fix

add a feature to allow reviewers to assign issues to a user, so he/she can fix the issues on his/her own.

List metric values of a module

It should be possible to get a list of metric values for a selected set of metrics and a selected set of commits aggregated on a certain module.

Depends on #42.

Project dashboard

Display a dashboard for a project.

Contents of this dashboard have yet to be defined.

API to read and write annotations

The annotations to git commits created by the annotator must be read from the git repository again by other components. For this, an API must be created.

Inremental Update

The Annotator should be able to update (pull) the local repository from the remote repository instead of always cloning the complete repository.

configure quality gate actions

Quality Profiles can be interpreted as Quality Gates (http://thombergs.github.io/coderadar/1.0.0-SNAPSHOT/docs/restapi.html#_quality_profile).

Add a REST endpoint to define constraints on metrics defined in a Quality Profile and to define actions that are to be performed when the constraints are not met.

Further specification required.

REST endpoint to receive reports from third party tools

Metrics that go beyond static code analysis like test coverage, findbugs (bytecode analysis) and similar tools, cannot be collected directly by coderadar (coderadar should not become a build server that has to run build tools like maven or gradle to create bytecode).

However, it should be possible to provide these metrics, for example by creating a report of some kind during a build on a build server like Jenkins and sending this report to coderadar.

For this scenario, coderadar should support a REST endpoint that receives a report (for example, a test coverage report by jacoco) and forwards it to an analyzer that translates that report into coderadar metrics.

Support multiple Branches

Currently, the annotator creates metrics for all commits, starting from HEAD and going back in time through THE FIRST parent of each commit, until there are no more parents.

Thus, branches are not supported and there is a slight randomness in the algorithm, since only the first parent is annotated.

Throttle continuously failing jobs

Currently, the job triggers run every couple seconds to evaluate if a new job is to be placed into the queue. If a job fails within the couple seconds it will be queued again and again, each time failing. The job then blocks a job executing server node.

Jobs that continuously fail (say 3 times in a row) should be given a timeout of 10 minutes or so until it is queued again. The trigger logic should be extended by this rule.

option to limit cloning of a remote repository to commits within a certain date range

Currently, directly after creating a project via the REST API, the remote repository will be cloned and scanned for commit and file metadata (see http://thombergs.github.io/coderadar/1.0.0-SNAPSHOT/docs/restapi.html#_creating_a_project).

For a very large repository, I might want to analyze a certain range of commits only. So, when creating a project, it should be possible to define a date range. Only the commits within this range should be cloned to the local repository to be analyzed later.

This is also important for creating a repeatable dataset for performance tests.

List findings in a file

Implement a REST endpoint that lists all metric findings in a file.

Namespace Strategy for metrics

Define a namespace strategy for metrics:

short namespace instead of fully qualified name of analyzer class
namespace must be registered with AnalyzerRegistry so that there can be no duplicates
add a localized display name for each metric