GitLocker: The Coding Marketplace

Description:

grosgatherer 1.0.0

Software development process data gathering

The Python modules in this repository gather data from different sources that
are used by software development teams and projects, as well as control
a distributed setup of data gathering. The data gathering modules are part of
Grip on Software, a research project involving a larger pipeline where the
gathered data is made available for analysis purposes through a MonetDB
database setup.
The following systems from software development processes are able to be
interacted with using the GROS gatherer modules, focusing on data acquisition:

Jira
Git, including additional repository data from GitHub and GitLab
Azure DevOps/VSTS/TFS, including Git-based data
Subversion
Jenkins
Quality-time
SonarQube
BigBoat

There are many ways to use the GROS gatherer, such as manual script usage,
Docker images, Jenkins jobs, agent-based Docker compose network isolation,
central controller instances and usage in other applications. However, this
README.md document focuses on the module installation and development. More
thorough documentation on compatibility with versions of data sources,
configuration, script overviews and agent-controller APIs is found in the
online data-gathering documentation.
Installation
The data gathering modules require Python version 3.8 and higher.
To obtain the latest release version of the module and its dependencies from
PyPI, use the following command:
pip install gros-gatherer

We recommend creating a virtual environment to manage your dependencies. Make
sure that python runs the Python version in the virtual environment.
Otherwise, the dependencies are installed to the system libraries path or the
user's Python libraries path if you do not have access to the system libraries.
Configuration
Some modules require the existence of settings and credentials files in the
directory from which the script importing the module is run. This path is
adjustable with environment variables. For details on configuration, view the
documentation.
Development and testing
Most of the modules come with unit tests, while also depending on the
correctness of dependencies to provide accurate data from sources (i.e. our
unit tests often use mocks in place of the dependencies) and testing the actual
system in non-production settings. To run unit tests in this repository, first
install the test dependencies with make setup_test which also installs all
dependencies for the modules. Then coverage run tests.py provides test
results in the output, with XML versions compatible with, e.g., JUnit and
SonarQube available in the test-reports/ directory. Detailed information on
test coverage is also obtainable after a test run in various report formats,
for example:

coverage report -m for a report on (counts of) statements and branches that
were hit and missed in the modules in the output.
coverage html for a HTML report in the htmlcov/ directory.
coverage xml -i for an XML output suitable for, e.g., SonarQube.

To perform all the steps except the HTML report, run make coverage. If you do
not need XML outputs (each test class writes an XML file by default), then run
make test to just report on test successes and failures or make cover to
also have the terminal report on statement/branch hits/misses.
GitHub Actions is
used to run the unit tests and report on coverage on commits and pull requests.
This includes quality gate scans tracked by
SonarCloud
and Coveralls
for coverage history.
The Python scripts and modules conform to code style and typing standards which
may be checked using Pylint with make pylint and mypy with make mypy,
respectively, after running make setup_analysis to install static code
analysis tools. The command for mypy provides potential errors in the output
and typing coverage reports in several formats, including XML (compatible with
JUnit and SonarQube) in the mypy-report/ directory. To also receive the HTML
report, use make mypy_html instead.
Finally, the schemas in the schema/ directory allow validation of certain
configuration files as well as all the exported artifacts against the schema.
For example, the Jira and Azure DevOps field mapping specifications are able to
be checked; see the issue
trackers
documentation section for an example.
We publish releases to PyPI using
make setup_release to install dependencies from requirements-release.txt
and make release which performs multiple checks: unit tests, typing, lint and
version number consistency. The release files are also published on
GitHub and from
there are archived on Zenodo.
Noteworthy changes to the modules are added to the
changelog.
License
Data gathering scripts and modules are licensed under the Apache 2.0 License.