Reaper is a tool used to assess a GitHub repository in the form of a score. It considers a number of different attributes in order to perform a thorough assessment.
Together with a database of metadata provided by the GHTorrent project, reaper considers both contextual information such as commit history as well as the contents of the repository itself.
The projects runs on systems with python3
. There are a number of python
libraries that the code needs in order to execute. To install them, simply run
pip install -r requirements.txt
(or pip3
if your system does not have python3 set
as the default.)
The main interface that should be used to run reaper is the Python script called
batch_score.py
. This script should be called with a set of parameters that
specify where the datasource can be found, what projects need to be analyzed,
etc.
Additionally there is a script called score_repo.py
, however at the moment it
is outdated and cannot be used to score repos.
batch_score.py
can be called as follows:
batch_score.py -c <config> -r <repos_path> -m <manifest> -s <sample_file>
Where:
<config>
: Is an instance ofconfig.json
.<repos_path>
: Is the path to a directory where reaper can check out the source files of a project.<manifest>
: Is an instance ofmanifest.json
(which can be found in this repository) containing information on what attributes should be executed.<sample_file>
: A list of GHTorrent project ids that should be analyzed, newline seperated.
This file is responsible for controlling various aspects of the system. There
are two high level keys that can be altered, options
and attributes
.
Key | Values | Description |
---|---|---|
threshold |
Positive Numbers | Defines the threshold by which the system considers a repository to contain a software project. |
persistResult |
true or false | Whether the granular results should be saved to the specified datasource. |
datasource |
object | Settings for connecting to the GHTorrent database, see description below. |
github_tokens |
list | List of GitHub OAuth tokens to be used for authentication for rate limiting purposes. |
GHTorrent is a research project that aims to collect
and store information produced by the public GitHub events feed. The initial
implementation of score_repo.py
relies on this information being accessible.
Load a dump of the GHTorrent data set into MySQL or MariaDB (binary compatible
as of this writing), copy the config.json.sample
file to config.json
and
edit the appropriate parameters under the options => datasource
key.
If persist results is enabled a database table needs to exist to which reaper can
write results. This table should be named reaper_results
and should contain at
least a column for project ids named project_id
, and a column to store the score
for a repository named score
. Additionally, there should be a column for every
attribute that you want to store.
For instance, to create this table in MySQL the following table create statement can be used:
CREATE TABLE `reaper_results` (
`project_id` int(11) NOT NULL,
`architecture` double DEFAULT NULL,
`community` double DEFAULT NULL,
`continuous_integration` double DEFAULT NULL,
`documentation` double DEFAULT NULL,
`history` double DEFAULT NULL,
`license` double DEFAULT NULL,
`management` double DEFAULT NULL,
`project_size` double DEFAULT NULL,
`repository_size` double DEFAULT NULL,
`state` varchar(255) DEFAULT NULL,
`stars` double DEFAULT NULL,
`unit_test` double DEFAULT NULL,
`score` double DEFAULT NULL,
PRIMARY KEY (`project_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
The system is designed as a number of plugins that all have a chance to analyze a given repository (both metadata as well as contents). A number of provided attributes are apart of the base distribution of the system, but more can easily be added.
In order for an attribute to be executed, it must be listed under the
attributes
key in the configuration file.
An example entry looks like the following:
{
"name": "architecture",
"dependencies": [
"ctags"
],
"enabled": true,
"weight": 50,
"options": {
}
}
name
refers to the name of the attribute as it appears under the attribute/
directory. dependencies
is a list of system utilities that the attribute
implementation relies on in order to function. enabled
controls whether the
attribute will be considered during the scoring of the repository. weight
allows the bias of the attribute to be fine tuned in order to adjust its effect
on the final score. Finally, options
are specific options for each particular
attribute implementation.
In order to add your own attribute plugin to the system, there are few things that must be done. First, add an attribute entry as described in the above section that refers to your specific attribute.
Secondly, create the appropriately named directory under attributes/
along
with a main.py
. Inside of this, the following function signature should be
used to kickoff the execution of the plugin:
def run(project_id, repo_path, cursor, **options):
# Implementation goes here.
Check the doc block for details on what each parameter provides in terms of
functionality. Attribute implementations should return a tuple of two values:
the binary result of execution and the raw result of execution. The binary
result should be True or False and the raw result should be a real number that
is the raw calculation made by the plugin. In the case of purely binary results,
do something like return result, int(result)
.
Additionally, there is the option of initializing the plugin. To take advantage
of initialization, add the following function signature to main.py
:
def init(cursor, **options):
# Implementation goes here.