-
Notifications
You must be signed in to change notification settings - Fork 48
Troubleshooting
Here are a few hints to help you troubleshooting when the execution of code-forensics, despite not exiting with a clear error, fails to generate any data or doesn't actually display any diagram.
Sometimes these issues can be resolved through a more accurate configuration of code-forensics, other times by passing the right parameters to the analysis task. Nevertheless, if both situations don't apply, then please submit a new issue and provide as much detail as possible.
Also, before starting to investigate a problem or logging a new issue, make sure that your question hasn't yet been answered in the FAQ page.
In order to help with troubleshooting you can run code-forensics in debug mode by setting the environment variable COMMAND_DEBUG to enable more verbose output, e.g.:
$ COMMAND_DEBUG=true gulp <analysis task>
In this execution mode code-forensics will display the exact script commands that are used to execute the vcs and code-maat programs. You may then run those commands manually, again to check the output for any anomalies.
The diagram belows attempts to visualise how the data is processed and transformed from its original source (the code repository) to its final destination (the data files in the output folder), and ultimately served to the browser
|----------| |---------| |---------| |---------------| |------------------| |-------|
|repository|==>|log files|==>|code-maat|==>|analysis output|==>|diagram data files|==>|browser|
|----------| |---------| |---------| |---------------| |------------------| |-------|
log dump task -------------> report task -----> analysis task -------> webserver task
Below are described three common categories of issues that can arise.
The log dump task consists of two steps:
- Log fetching: execute the vcs command to list the revisions falling into the given date range.
- Log normalisation: filter out the file paths corresponding to each revisions according to the repository settings (i.e.
rootPath
includePaths
andexcludePaths
parameters). If at the end of this step no actual file paths are included in the log files the program stops with an error, because there is no relevant data for the analysis.
- Check the output of the log task. The log files are located under the configured tempDir and are named after the date/time period specified for the analysis, e.g.:
vcslog_normalised_<date-range>.log
Here is a sample log file generated for a git repository:
--0d45e709f--2018-11-19--<author name>
--2d6a68c28--2018-11-19--<author name>
1 1 config/defaults.yml
--7a958bce6--2018-11-17--<author name>
3 3 config/cucumber.yml
4 4 features/step_definitions/aspects_steps.rb
2 2 features/step_definitions/post_with_poll_steps.rb
--a09f7d73d--2018-11-17--<author name>
--a6655c187--2018-11-08--<author name>
2 0 features/support/env.rb
1 1 features/support/publishing_cuke_helpers.rb
1 1 features/support/user_cuke_helpers.rb
Inspect the content of such files.
- Check that the dates of the commits are within the expected date range
- Check that the listed file paths correspond to the configured repository paths parameters
Another possible cause of incorrect or incomplete log data generation is the modification of repository paths configuration in between analysis runs. code-forensics does not attemt to generate a log file for a given period of time if such file already exists. However if the repository configuration paths have changed since the last log task execution there is a good chance the log files contains incorrect or incomplete data.
- Make sure you re-generate the log files whenever you update the repository configuration paths.
The diagram data files are located under the configured outputDir, inside a folder named after a randomly generated reportId
, which you can identify from the url used to access the diagram visualisation, e.g. http://localhost:3000/index.html?reportId=<random id>
.
- The report folder should contain a
manifest.json
file. The manifest include report metadata and references to other generated files (dataFiles). Below is an example:
{
"id": "35b103e5bb4ca4897c21c65611e4cbc12f54d29a",
"reportName": "developer-coupling",
"taskName": "developer-coupling-analysis",
"time": "2018-12-25T05:27:52.990Z",
"dateRange": "2011-01-01_2011-12-31",
"parameters": {
"maxCoupledFiles": 5
},
"enabledDiagrams": [
"main-developer-coupling",
"communication-network"
],
"dataFiles": [
{
"fileType": "communication-network",
"timePeriod": "2011-01-01_2011-12-31",
"fileUrl": "35b103e5bb4ca4897c21c65611e4cbc12f54d29a/2011-01-01_2011-12-31_communication-network-data.json"
},
{
"fileType": "code-ownership",
"timePeriod": "2011-01-01_2011-12-31",
"fileUrl": "35b103e5bb4ca4897c21c65611e4cbc12f54d29a/2011-01-01_2011-12-31_main-dev-coupling-data.json"
}
]
- Each dataFile should exist and not be empty.
This is a more advanced type of troubleshooting, which requires you to know how to debug javascript running in your browser. Any modern browser should have some kind of developer tools plugin/function to enable the inspection of its javascript console. If you see any error being printed in that console when opening the web page for a particular diagram/report then there is the most likely reason for the failure. Make a note of the error and please log a new issue.