LGTM Enterprise 1.24

Administration FAQs


What's the version number?

Click General settings in the side bar to display the version information.

How do I update the license?

  1. Click General settings in the side bar to display the current license details.
  2. Click Browse to display a file selection dialog box.
  3. Locate the license file and select it.
  4. Click Open to confirm the selection and close the dialog box.
  5. Click Upload to load the new license file.

What hardware resources do we need for an LGTM Enterprise deployment?

The question is a little open-ended without knowing more about your projects. There are many different aspects to consider, not just the number and size of projects. Two projects of the same size may take very different lengths of time to analyze (perhaps due to different build systems being used). You may, or may not, have many users who will regularly want to run queries from the query console. You may want to enable automated code review for all, or only some, projects. And your projects may be extremely actively developed, or development may be less active.

Typically an LGTM Enterprise deployment is distributed across multiple virtual machines, for example:

  • One "controller" machine running the system's core services
  • One web app host machine
  • Multiple worker host machines—depending on the number and size of your projects and how actively they are being developed.

Because resource requirements are difficult to calculate in advance, it is advisable to plan for an incremental deployment, increasing resources as it becomes necessary. The following requirements for controller and web app host machines give an idea of a typical base for an initial deployment.

LGTM controller machine

This machine runs all of the control pool services except for the web application and the web proxy service (for more information, see Services).

  • 8 cores
  • 16 GB RAM
  • 1 TB free disk space
  • Solid-state drive (SSD)*

LGTM web app host

  • 2 cores
  • 8 GB RAM
  • 50 GB free disk space
  • SSD recommended*

* We recommend that you use solid-state drives (SSDs) rather than hard disk drives (HDDs) for all of the machines, in both the control pool and the work pool. We strongly recommended that you use an SSD for the "controller" machine, as files are served from here to all other cluster machines.

LGTM worker hosts

Worker host machines run one or more worker daemons that perform the "heavy lifting" involved in building and analyzing your projects. The number of worker daemons you need depends on the amount of work that needs to be processed and various aspects of your projects, such as the build commands that are required and the number and size of dependencies for each project. You can choose to run several workers on a well-resourced machine, or just one or two workers on a less well-resourced machine.

For details of how to estimate an initial requirement for worker host machines, see Work pool hardware requirements.

How do I provide system data for a support request?

When you contact GitHub Support it's very useful to include system data that we can use to diagnose the issue and help you fix it. Run the lgtm-support-bundle command to generate a file containing this data.

Can LGTM analyze private projects from cloud-based services?

Yes, LGTM Enterprise supports private repositories for all cloud-based host systems for which there is an integration. These include Azure DevOps Service (previously called VSTS), Bitbucket Cloud, GitHub.com, and GitLab.com—see System integrations. The integration ensures that the access rights to such projects, configured in the host system, are respected in LGTM Enterprise.

How do I add a project that LGTM can't build?

Some codebases are so large, or have such complex build environments, that it doesn't make sense to create specialized LGTM worker hosts to build them. In these cases, it's often best to use your existing infrastructure to create a CodeQL database for your project. Then you can use the rest API to create an LGTM project with the special upload analysis mode and upload the database for analysis. For more information, see Using upload analysis.

Where do I find a project's immutable ID?

  1. Click Projects in the side bar to display the project pages.
  2. Find the project you're interested in.
  3. Click the project name to display detailed information.
  4. The External immutable ID is shown on the Info tab under Basic information.

Why can't I display the full log file?

You should be able to display the full log file for any of the jobs run by LGTM (for details, see Exploring work pool logs). If you click a link and the log file can't be displayed, there are two possible reasons:

  1. Routine housekeeping tasks have deleted the file.
  2. Your external URL is misconfigured, so the link to the log file is wrong.

If the file has been deleted, you cannot retrieve it. If the log file was for a failed attempt-build job, then you can retry the build to rerun the job.

It's always worth checking that your external URL is correctly configured. If this is wrong, you may also have problems uploading a license, logging in with an external account, or analyzing pull requests. In addition, any links included in emails sent to users will be wrong. You can check the external URL on the Settings page. If your current browser URL doesn't match the external URL shown on this page, a warning message is displayed.

Why hasn't the latest commit been analyzed?

LGTM polls each repository once every 24 hours to find out if there are any new commits to analyze. Poll jobs are scheduled to be spread evenly across the 24-hour period, with the poll job for a specific repository occurring at roughly the same time every day. The result is that LGTM does not start to analyze a new commit until after the repository has been polled, which may be up to 24 hours after the code change was merged.

If someone needs to see analysis results more quickly, you can trigger a manual poll job. Go to Projects > <project name> > Repository and click Poll repository. Better still, if you enable automated code review for a project, LGTM alerts are reported in your repository host system when developers raise a pull request. That way they can fix issues before the code is merged into the repository. For more information, see Managing automated code review in the user help.

How does LGTM know when the appropriate branch of a repo has new commits?

LGTM polls each repository once every 24 hours to find out if there are any new commits to analyze. Poll jobs are scheduled to be spread evenly across the 24-hour period, with the poll job for a specific repository occurring at roughly the same time every day. The result is that LGTM does not start to analyze a new commit until after the repository has been polled, which may be up to 24 hours after the code change was merged.

If someone needs to see analysis results more quickly, you can trigger a manual poll job. Go to Projects > <project name> > Repository and click Poll repository. Better still, if you enable automated code review for a project, LGTM alerts are reported in your repository host system when developers raise a pull request. That way they can fix issues before the code is merged into the repository. For more information, see Managing automated code review in the user help.

As regards the "appropriate branch"—LGTM only analyzes commits made to the default branch of a repository, as defined in the repository host system.

Why can't I see projects I've added with a new repository host integration?

You have added a new integration and then added projects from that repository host. The projects have been added successfully in the Projects page of the administration interface. However, when you go to the main interface the projects are not listed.

The issue may be that the projects are private. Check the authorization mechanism used in the integration settings (see Defining integrations with external systems). If this is set to Private, no one will see the project in the main interface unless they are explicitly given FULL access in the settings page for an individual user in the administration interface (see Overriding authorization for all projects associated with an integration). By default, users can only see a very restricted amount of data relating to projects added from a repository that uses the Private authorization mechanism. For more information, see Restricted authorization.

How many API requests does LGTM make to integrated services?

The volume of requests to an integrated service, such as an instance of GitHub Enterprise Server, or to Microsoft Azure DevOps Services, varies depending on your LGTM deployment. The majority of API requests are for authorization purposes, so the most important variables that determine the volume of requests are the number of active LGTM users and the number of projects for the external service in question.

The following equation gives a rough idea of the number of API requests that LGTM Enterprise might make to an external service on any given business day:

(number of projects from the integrated service) x (number of active LGTM users)

Why are no issue tracking tickets being raised?

You have added an issue tracker integration but no issue tickets have been raised for some projects. There are several possible reasons for this.

  • No new analysis yetLGTM Enterprise polls repositories once a day for changes to each project and then analyzes any revisions. No issue tracking updates will be made until the daily poll job has been performed. If you want to force LGTM Enterprise to poll for changes to a project, go to Projects > <project name> > Repository and click Poll repository.

  • Query filter too restrictive—The query filter you have defined for the issue tracker integration may be too restrictive to match any alerts. Try modifying the filter on the integration's settings page. For information about the syntax of query filters, see Configuring issue tracking.

  • No new alerts—By default, issue tickets are only raised for new alerts, identified by LGTM Enterprise after you added the issue tracker integration. If you want to raise issue tickets for all existing alerts, clear the Only create issues for new alerts check box on the integration's settings page.

  • Issue tracker integration turned off—Issue tracking integration can be turned off by default for all newly added projects, or it may have been turned off for a specific project. You can turn on issue tracking as follows:

    1. In the administration interface, go to Integrations > <issue tracker integration> and check whether the Automatically track issues for new projects check box is selected. If you want issue tickets to be created for alerts identified in all, or most, projects as soon as the project is added, select this check box.
    2. For each project that you want to use issue tracking, go to Projects > <project name> > Analysis settings and check that the Create tickets for alerts in this project check box is selected.