Integrate CodeScene with Pull Requests¶
CodeScene offers an automated integration with GitHub, BitBucket, Azure DevOps or GitLab pull requests to incorporate the analysis results into existing delivery workflows.
Integration is different per provider:
Github via Checks
Bitbucket via either Builds or Code Insights Reports
Azure Status Check and Pull Request comment
GitLab via Merge Request Discussion comment
CodeScene and Pull Requests: Use Cases¶
The purposes of CodeScene’s pull request integration is to:
Specify quality gates that trigger in case the Code Health of a hotspot declines.
Serve as a quality gate and provide feedback on user-defined hotspot goals (e.g. Supervise, Planned Refactoring).
Prioritize code reviews based on the risk of the commits.
Get early warnings on new and complex code, and detect the absence of expected change coupling to catch omissions.
Quality Gates for declining Code Health¶
CodeScene integrates with pull requests via GitHub’s checks API. That way, CodeScene can act as a (soft) quality gate during development. If a hotspot declines in health, CodeScene detects it, fails the checks, and presents the details:
CodeScene’s Quality Gates focuses on Trends, not absolute values¶
You might look sceptically at automated quality gates. After all, many code analyses are noisy with tons of warnings in code you haven’t even touched or didn’t write yourself.
CodeScene takes a different approach and its quality gates emphasize trends over absolute values; is a hotspot getting better or worse?
CodeScene uses the current state of the code as its baseline during the PR review. This limits the feedback to information that’s relevant and actionable; we never want our code to get worse no matter what level we start at. Trends are actionable.
Prioritize Code Reviews via the predicted Delivery Risk¶
In many organizations, code reviews tend to become bottlenecks. There’s only so much code we can review each day, and after a while it becomes easy to slip. Suddenly, a critical error makes its way to production.
To help optimize code reviews, CodeScene recommends a code review level based on the predicted delivery risk of the PR:
Use the recommended review level as a guideline to save time during code reviews.
How are high risk PRs identified?¶
So how can CodeScene predict the necessary review level? Under the hood, CodeScene calculates a unique risk profile for your codebase based on how the system has evolved. This risk profile is a combination of technical and social metrics. The technical metrics relate to the depth and diffusion of the change – the more changes and the more widespread, the higher the risk.
The social dimension of the risk profile relates to the experience of the programmer doing the change. Note that experience is relative to a specific repository, and measured as how much each programmer has contributed to your code historically.
Finally, the emphasize is on _prediction_; while it’s likely that a detected high risk change contains a bug, the tool cannot guarantee it, not can it guarantee that lower risk changes are bug free. It’s all about probabilities.
Enable the Pull Request Integration¶
Navigate to your project’s configuration in CodeScene, navigate to Pull Request Integration settings.
If you’re using GitHub the first step is to install the GitHub app for the integration. CodeScene will inform you of this step, if needed:
With the app installed, all you need to do is to check a box and you are up and running with a single click:
If you are using Bitbucket you’ll need to install an Atlassian Connect App on the Workspaces of repositories of the CodeScene project, there is a link on the configuration page to install it.
Pull Request Analysis Results Presentation¶
To see how results are presented as GitHub checks see the images above. This section shows presentation in other providers:
Bitbucket result presentation¶
The default presentation with Bitbucket is the Build option. Analysis results will be presented in a Pull Request comment and as a Build status. The Build status can be made a requirement for merging the Pull Request.
Alternatively you can get a Code Insights Report, which will not prevent merges if you have configured successful builds to be a requirement.
Azure result presentation¶
Results are presented as status check and a PR comment.
You can make the check mandatory for merging into a specific branch:
go to Azure’s Project Settings
select a repository
select “master” or similar main branch in Branch Policies
Status Checks, click + button to add one
On this same page you can also enable: Check for comment resolution. Since CodeScene’s PR comments on failed checks are Unresolved, this setting forms a Quality Gate that prevents PR merging, unless PR comment is manually marked as resolved. This gives a nice flexibility where CodeScene’s failed PR check can be manually overridden.
GitLab result presentation¶
Results are presented as Discussion comment in the Merge Request:
If PR check is successful then the comment is resolved, otherwise it’s unresolved. Status is shown with a green checkmark (red arrow points to it).
This is useful if you set the restriction to prevent merge if there are unresolved comments.
Set Up an Automatic Analysis Schedule¶
CodeScene will always try to fetch the latest version of every file changed in a pull request, but it won’t do that for large pull requests containing more than 30 files.
To get the best results for the Pull Request Integration checks, it’s a good idea to set up an automatic full analysis for your project.
You can do this in the Analysis schedule section of the project configuration. See the Getting Started section to learn more about this feature.
Pull Requests: Statistics, Actions, and Impact¶
No matter what baseline we start from, we never want our code to become harder to read, understand, or maintain. CodeScene’s pull request integration lets you stay on top of your development so that you can prioritize and act upon any negative trends. For that purpose, CodeScene visualizes the impact of pull requests over time:
The presented statistics are:
Checks performed: This is the total number of pull request analyses run by CodeScene.
Detected Violations: A violation is either a violated goal (e.g. a planned refactoring never happened), a reported code health decline, or new code with code health issues.
Positive Actions: A positive action is when one of the detected violations is acted upon and mitigated.
Violations Ignored: This is the number of detected violations that were merged as-is, without remediation, to the main branch. Ignored violations lead to a failed goal and/or a code health decline.
CodeScene also calculates the total code health impact and presents it as monthly trends. These trends let you visualize and communicate improvements, as well as taking actions upon a larger decline:
In the preceding example, we see that Codebase A took on a significant amount of technical debt during November. This code health decline would also be reported as alerts on the CodeScene dashboard when the pull requests are merged. A recommended action in this case would be to plan goals to manage the new debt (see Manage Hotspots and Technical Debt with Goals).
Contrast this with Codebase B which shows a positive trend where smaller code improvements are delivered continuously.
Finally, you can inspect the details of individual pull requests if you need to drill down even further:
You can find the pull request statistics on your project’s analysis dashboard:
Enable CodeScene’s Status Badges¶
At this point you might want to add CodeScene’s status badges to your project as well. Status badges allow your teams to keep an eye on the health of their projects at a glance:
The status badges are intended for embedding in your GitHub README file. Sample GitHub markup is provided on the “Status Badges” configuration tab.
Constraints and Limitations¶
CodeScene’s pull request integration requires a paid plan.
Pull requests created from forked repositories are supported with a caveat: If the fork’s branch (from which the PR has been created) is not up to date with the corresponding upstream repository’s main branch then it’s possible that CodeScene fails to detect a code health decline (or an improvement) due to obsolete versions of changed files in the fork. This should only happen when the files modified by the PR has been changed, in the meantime, in the upstream repository . A recommended remedy is to keep forks synchronized with upstream repositories.