LGTM Enterprise 1.24.1

About automated code review

By default, LGTM analysis is only run on the default branch in the repository host, so you only learn about problems with code after they've been merged into the repository.

The default branch is configured by the repository owner, and can be set to a different branch in the repository host, if required.

You can set up LGTM to run checks or builds (depending on your repository host) automatically on each pull request, so that you can fix any new alerts caused by changes in the pull request before the code is merged into the repository. Enabling automated review of pull requests doesn’t block the merging of pull requests. This is not something we encourage, but you can just merge pull requests that introduce alerts. You may want to do this if you think that the alerts flagged by LGTM are not important, or not worth fixing. Also, note that you can tell LGTM to only show alerts that matter to you. For more information, see Showing/hiding query results.

For a list of repository host systems for which you can set up automated code review of pull requests, see About LGTM. For Git repositories, you can also request a code review of an arbitrary patch using the API's /codereviews endpoint.

You can set up automated code review for pull requests for an LGTM project if you are an administrator or the owner of the code repository.

For more information on how to enable and manage automated code review, see Managing automated code review.

There will be a delay between the submission of a pull request and LGTM posting a review comment on that pull request. The turnaround of automated code review depends on many factors. For more details, see What's the speed of LGTM posting a review comment to a pull request?

How does it work?

The pull request integration uses the standard Status API, so LGTM analysis is triggered and displayed on pull requests in the same way as other checks/builds. LGTM fetches the code for the pull request and for the head branch. Both revisions are analyzed to determine the impact of merging the pull request on new/fixed alerts (see Code analysis). One check/build runs for each language analyzed by LGTM.

If you submit a pull request when LGTM Enterprise is down, it's very likely that the code review will be lost. Wait until LGTM is back up and running, and push a new commit to the pull request. This immediately re-triggers the code review by LGTM.

Let's look at examples of automated code review for pull requests in GitHub and Bitbucket:

On GitHub

Example of PR checks in GitHub

Each LGTM check has a details link—click through to LGTM to see details. When the checks are complete, the pull request status reports how many alerts would be introduced or fixed by merging the pull request—you can click through to show the full results in LGTM.

On Bitbucket

Example of the build status in Bitbucket

The build status summary, on all pull request pages, includes any LGTM builds. Click the status icon to display the build summary (). Then click through to LGTM for full details ().

How are the results displayed in LGTM?

When automated code review for pull requests is enabled, you can see a detailed view of results for individual pull requests on LGTM.

The Automated code review section of the Integrations tab has two tabs:

The most recent requests are shown at the top.

You can access a more detailed page for each request listed. On that detailed view, you can perform a variety of tasks, such as retrying analysis that failed. For further details, see Using automated code review.

Alternatively, you can access that view from your repository by clicking the link for an LGTM analysis (links in blue, shown on the two screenshots above). A page similar to the screenshot below is displayed:

Automated code review results

Pull request details

Alert status for each language. For example "No alert changes" or "2 new alerts and 2 fixed alerts". If any of the analyses fails, there's a red cross instead of the green tick and a link to the log files is provided in place of the alert status information.

Detailed results for new and fixed alerts for each changed file.

Alert message and exact location within the source file. From the alert message, you can:

  • Suppress the alert if you think it shouldn't be flagged.
  • Display the help page for the query that found the alert.
  • View the alert within the entire file.

For more information, see Drilling into an alert.

More information

To find out more: