The work pool consists of one or more "worker" host machines (or containers in a Dockerized deployment). The workers hosted on the machines in the work pool are daemons that carry out the "heavy lifting" tasks of building and analyzing code.
In the simplest, non-Dockerized, demo setup the work pool and the control pool may be hosted on the same machine and you may only run the minimum of two worker daemons (one for processing users' custom queries, one for all other work pool tasks).
For deployments, the work pool will consist of multiple virtual machines, each of which may host multiple LGTM workers. In a Dockerized deployment, each worker daemon runs in a separate Docker container.
It's important to distinguish between "workers" (the daemons that build and analyze code) and "worker hosts" (the machines on which the workers run).
The workers in LGTM's work pool should not be confused with the "task workers" that run in the control pool. The latter are instances of a service that performs background tasks for the system.
Each worker can access three types of resource:
Workers can download source code from a repository.
- File store
Workers download files from the file store in the control pool. Files include CodeQL files and project configuration files. After analysis, workers upload data to the file store—for example, CodeQL databases for a project, which also contain query results and a source archive.
- Job dealer
Workers poll the job dealer for the next job to work on. Some workers are configured only to retrieve jobs that run user-defined queries from the Query console, to ensure these are processed quickly. If a worker has one or more labels assigned to it, it retrieves jobs with matching labels in preference to unlabeled jobs, and ignores any jobs with other labels. On completion of a job, the worker informs the job dealer.
The arrow directions on the diagram give an indication of data flow between system components.
For information on managing the work pool, see Managing the work pool.