mezuro / kalibro_configurations Goto Github PK

This line is not being covered.

Like clonning a existing configuration and may provide in the future about fork count for each configuration like github forks.

More info at:

mezuro/prezento#48
https://github.com/mezuro/prezento/wiki/Reading-and-ReadingGroup-clone-behaviour

The setup script does not create the test database and it assumes that it is already created. Therefore, it is necessary to manually run:

RAILS_ENV=test ./bin/setup

Maybe the setup script should also run this step as well.

The default rails server is getting used by the packaged distributions. Thus it is using webrick which is known to not be able to handle large loads os requests. Rails 5 already feature puma as the default webserver.

Here we want to:

• Install puma
• Configure puma

This might fix huge delays on mezuro.org.

The validation added by 673df16 would be better placed at a validator (http://guides.rubyonrails.org/active_record_validations.html#custom-validators).

This would make the create and updateactions on MetricConfigurationsController simpler as well.

Currently, we only calculate the relation between a given metric and all the metric configurations.

We could present even more useful information if we had more statistics on the data we have stored. In this direction, we could aim to answer the following questions:

• What are the most used metrics?
• For each metric used, what are the most used ranges?
• What are the differences and similarities between the metrics and ranges used across the supported programming languages?
• What types of metrics are most used on the supported programming languages? Security, structural, hotspot metrics, etc?

We should not trust the parameters from the web and use the permit method when getting parameters on controllers.

We should be doing this in all the application controllers.

It is broken since it does metric_configuration.kalibro_ranges.each, but that yields an empty list. It's necessary to call the all method before calling each, so it will actually check existing ranges correctly.

Since we allow metric configuration updates, it would be a good idea to persist metric configuration snapshots.
That would avoid inconsistencies when processing a repository.

For example, if one changes the script of a compound metric configuration, that metric's meaning would not be the same on different metric configuration snapshots.

If you install the gems just for the production environment, the require 'database_cleaner' breaks the server startup.

There some metrics that are supposed to be part of compound ones. Those have no meaning by themselves and should not affect the project grade.

So it would be useful to have a special case of MetricConfiguration with no ranges and so that KalibroProcessor do not try to interpretate nad incorporate in the grade.

ReadingGroupsController is returning unprocessable_entities instead of not_found status when resources do not exists.

This raises many KalibroClient::Errors::RequestError on Prezento.

The setup script tries to touch the file tmp/restart.txt. However, it does not check if the tmp dir already exists, breaking the script if that is the case.

Currently it executes the validators even if the attributes beginning and end are not numbers

Kalibro Processor has no need for the asset pipeline gems on any environment or for sqlite3 under production (see mezuro/prezento#273).

Currently it seems some places properly create/use the languages field in Metrics, and others do not. We should decide what to do with it, and make sure everything is uniform.

At http://mirror.centos.org/centos/7/os/x86_64/Packages/ you can find the default version (I believe 2.0.0-p598)

Currently the JSON serialization converts from Float to String, but the opposite direction is never done. This causes Infinities to be converted to 0 sometimes, or comparisons to do strange things instead of working correctly.

Can't we redefine this validation? In some cases, having weight equal to zero may be useful.
For example, the blank lines metric from Radon, since it does not have any meaning by itself. Is only means something when compared to the total number of lines. Therefore, assigning a range for it may be confusing.

Allow configurations to have a language associated.

This will enable automatic association of configurations to repositories accordingly to their main language.

• Update gems
• Check configuration changes (http://railsdiff.org/)
• Fix broken tests

What is the version of the postgresql Indicated to use on development environment ? 9.1 or 9.3 ? The reason of question is because on the Readme of prezento the Indicated version is 9.3.

In what situations are we using the metric snapshot routes?

They need the metric snapshot id, but the user should not even know it.

If there are no use cases, maybe we should remove them.

How can we decide the thresholds for the ranges of the LOC metric on Radon?
Using the same values as Analizo does not seem good.
@marcheing and I have found that the file with highest LOC value on the python 3 standard library is somewhere between 4 and 5 thousand.
Any ideas?

The new method defined after the addition of rubocop.

The meaningful way to aggregate the metric Lines of code is by the sum. But it is hard to produce meaninfu ranges with this aggregation form once or the values are too loose for METHODS and CLASSES but correct for SOFTWARE. Or the range interval is too smal for the SOFTWARE granularity and correct for the CLASS and METHODS.

In order to address this, we need to provide ranges that may vary accordingly to the granularity.