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.
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?
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:
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.
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 ().
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:
- Pull requests—lists recent pull requests for the currently selected project.
- On demand—lists any code review requests made via the API.
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:
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.
To find out more: