Sprkl provides a dashboard that combines the information the analysis provides and the code execution. The dashboard includes several areas filled with relevant information about your recent code change and its implications.
The dashboard contains multiple sections. Each section has its unique structure. A commonly used record in every section is the code block reference.
The errors section aggregates errors found during the application execution.
There are two types of errors:
- 1.Errors were thrown through the code changes that were analyzed.
- 2.Errors that were found on infrastructure/library code execution (spans).
An error thrown through code changes will contain the code block reference alongside the error message display.
The coverage is not regular code coverage, as we know. This is a git-analysis-based coverage, meaning the coverage relates to blocks that were analyzed and marked as relevant (checkout Analysis). It's a critical metric that can tell you much about your testing in relation to the code changes you've made - Did I test all the code under the commit or pull request I'm pushing?
The coverage is split into two categories: covered and uncovered.
The covered subsection contains records of executed code (found related spans). Each record represents a code change. The uncovered subsection contains code you have that was scanned, but no runtime execution was detected (no relatable spans).
Insights are not necessarily errors but opportunities for you to identify specific areas in your recent code change that can be improved. It helps you ensure that your code performs better and prevents particular issues from being pushed to production.
A couple of insights provide are:
- Circular call: We found an HTTP request being made where the server and the client are of the same host. Meaning the request was made to a service by itself. This might be ok, but sometimes, it is better to call an internal function or method instead of performing a network-involved request.
- Async work added: We found a non-blocking operation that takes a very long time and is related to the code marked in the analysis.
- API performance impacted: We found that the marked code change execution takes a large chunk of time as part of an API request. This can indicate you have added a significant amount of work to your API.
Interactions show the ripple effect of your recent code change on the different system components. You can see details on HTTP requests, including the appropriate methods and database queries, including collections and procedures, queues, and other components. You can also see the details of your Jest tests execution, including tests that passed through the recent code change and tests that didn't, mocks, and assertions.
We support the following components:
- Databases: Any database instrumented with OpenTelemetry. A detailed view is provided for MongoDB, SQL, and Redis databases.
The security section aggregates the REACHED vulnerabilities (CVEs) found during execution. Sprkl will report to you actual packages loaded during runtime and called, which contain security vulnerabilities.