Admin Settings Reference
The Admin perspective provides a view for configuring various settings in Teamscale. Options that are not explained elsewhere are listed here:
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 Whitelist
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 Whitelist option allows Teamscale administrators to set global file-system access restrictions which affect all Teamscale projects, so they cannot be overridden by project administrators.
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.
Teamscale allows seamless monitoring with Prometheus.
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
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.