Admin Settings Reference
The Admin perspective provides a view for configuring various settings in Teamscale. Options that are not explained elsewhere are listed here:
TIP
You can also configure all of these settings using a configuration file.
Category: Server Settings
Setting: Teamscale instance base URL
This allows to set the URL Teamscale is running in. The value here is important for providing links to Teamscale in notification emails and exported files.
Setting: Shadow Mode
Useful when setting up a "mirror" Teamscale instances with the same configuration as an existing instance, e.g., for preparing an update. During the time when the new instance is online but not yet ready to be used in production (e.g., while performing history analysis), Shadow Mode should be enabled for that instance. In this mode, Teamscale will not publish data to external systems (e.g., via notifications or merge-request annotations). This does not, however, affect operative services like instance monitoring.
ABAP integration in Shadow Mode
The shadow mode will also prevent synchronizations of the ABAP Git bridge.
Setting: File-System-Access Allow List
Teamscale supports a generic connector type that can read any kind of directory structure from the local file system. However, security policy may mandate that project administrators, as opposed to Teamscale administrators, should not have access to the entire file system. The File-System-Access Allow List option allows Teamscale administrators to set global file-system access restrictions which affect all Teamscale projects, so they cannot be overridden by project administrators.
Category: Git
This setting is relevant when Teamscale should connect to a Git repository over Secure Shell (SSH).
Setting: Repository Clone Directory
Allows to configure the path to the directory where Teamscale stores clones remote repositories (e.g. Git or SAP). Relative paths are supported and defaults to a folder repo in the JVM process working directory.
Category: Server Limits
This section describes the configurations to help protecting the server from being overloaded by too many requests.
Setting: Pre-Commit Limits
Pre-commit analysis is triggered from the IDEs by developers. If a high number of developers is using this feature, a considerable number of requests is sent to the Teamscale server. The maximum number of files and the maximum individual file size per pre-commit as well as the minimum waiting time between pre-commit requests can be configured.
Setting: Late External Upload Processing
When external analysis data (e.g., coverage) is uploaded to Teamscale, a rollback is performed to integrate the external data with code from the repository. Especially for old uploads that require a rollback of several days, the following reanalysis can take a considerable amount of time. As a solution to this problem, Teamscale can postpone these uploads to a time where such a reanalysis does not disrupt normal operation, e.g., during the night.
The setting requires a crontab expression that defines at which time rollbacks and reanalysis from those late uploads may be performed, and a threshold that defines how many minutes in the past an upload must be to be considered old. The setting is active if a non-empty crontab expression is provided.
Category: Monitoring
Teamscale allows seamless monitoring with Prometheus.
Prometheus Service
To enable this service, the option Enable Prometheus metrics service endpoint must be enabled. Additional protection of the metrics can be provided by option Secret used to protect the metrics endpoint. If this is set, the URL needs to be accessed with api/monitoring/prometheus?token=<secret-token>.
Furthermore, the environment variable TS_PROMETHEUS_METRICS_PREFIX can used to define a common prefix for all exposed metrics.
Push Prometheus Metrics
In some situations, it might be impossible for the Prometheus instance to reach Teamscale's metrics endpoint. In such a case, we offer pushing the metrics in regular intervals with the option Regularly transmit Prometheus metrics to a webserver. Administrators might find it necessary to monitor shadow instances separately from production instances, which is why we also support sending metrics to a different webserver, should the instance be in shadow mode. You can find more information on the concept of pushing metrics in the Prometheus documentation.