Configuring a Git Repo

Since version 3, Scap is now able to deploy any git-based repository from our deployment server to any number of hosts. This deployment can happen in serial or in parallel. All that is necessary, aside from the configuration outlined here, is that the target hosts are accessible via SSH by the deploy_user from the deploy_host (the machine from which you run Scap).

Scap configuration is loaded from several files via scap.config.load() function in the scap.config module.

scap.config.load(cfg_file=None, environment=None, overrides=None, use_global_config=True)[source]

Load configuration.

A configuration file consists of sections, led by a [section] header and followed by name: value entries. Lines beginning with '#' are ignored and may be used to provide comments.

A configuration file can contain multiple sections. The configuration object is populated with values from the global section and additional sections based on the fully qualified domain name of the local host. For example, on the host deployXXXX.eqiad.wmnet the final value for a given setting would be the first value found in sections: deployXXXX.eqiad.wmnet, eqiad.wmnet, wmnet or global. Sections not present in the configuration file will be ignored.

Configuration values are loaded from a file specified by the -c or --conf command-line options or from the default locations with the following hierarchy, sorted by override priority:

  1. $(pwd)/scap/environments/<environment>/scap.cfg or $(pwd)/scap/scap.cfg (if no environment was specified)

  2. /etc/scap.cfg (if use_global_config is true)

For example, if a configuration parameter is set in $(pwd)/scap/scap.cfg and that same parameter is set in /etc/scap.cfg the value for that parameter set in $(pwd)/scap/scap.cfg will be used during execution.

  • cfg_file – Alternate configuration file

  • environment – the string path under which scap.cfg is found

  • overrides – Dict of configuration values

  • use_global_config – A boolean indicating if /etc/scap.cfg should be read


dict of configuration values

Simple initial setup

For a new repo setup, the main file that needs to be created is in the root of the repository at scap/scap.cfg. This new file should be made in ConfigParser format.


These values must be set in scap/scap.cfg:
  • git_repo

  • dsh_targets.

Available configuration variables






(String) Server from which code is fetched. Use is not recommended! The deployment-host will have a good value set for this already.


your username

(String) User as whom to ssh to target hosts and execute remote commands



(String) Repo on git_server



(String) Directory on targets in which your repo is placed



(String) Specific git rev to deploy.



(Boolean) (Optional) Whether submodules need to be fetched and checked-out as part of the deploy on targets.



(Boolean) If True, submodules will NOT be fetched from git_deploy_server, but from the git server defined in .gitmodules



(Boolean) (Optional) Whether binary files are managed via git-fat and should be synced as part of the deploy on targets.



(String) (Optional) Binary files should be managed by an external program. Allowed values are git-fat and git-lfs. Multiple values are allowed separated by commas



(String) Path to list of deploy targets. If the path is not absolute, Scap looks for a file in /etc/dsh/group. For an absolute path, it just uses the full path to the file.



(String) (Optional) If this option is defined, Scap will deploy to these groups of servers in order. If this is not specified scap will deploy to a single group of servers - those listed in dsh_targets

For example: server_groups: 'one, default will cause Scap to look in the scap.cfg file for both a one_dsh_targets file and a dsh_targets file (the default). A full deploy will run for hosts defined in one_dsh_targets, then a full deploy will run for hosts defined in dsh_targets (any hosts defined in both will be deployed with the first group–can in this example)

group_size [group]_group_size


(Int) (Optional) If defined, Scap will split each server group into smaller subgroups containing no more than the given number of hosts. A global and/or group specific configuration may be provided.

This configuration can be used to achieve a more serial deployment within each server group.

failure_limit [group]_failure_limit


(Int or String) (Optional) Number or percentage of group targets that are allowed to fail without triggering a rollback. Percentages should be suffixed with ‘%’ (e.g. 10%).

A global and/or group specific configuration may be provided.



(String) (Optional) If a service name is defined, the service will be restarted on each target as part of the promote stage.

May also be a comma-separated list of services to restart (e.g. service1, service2).

Each service may be reloaded instead of restarted by appending =reload to the service name (e.g., service1, service2=reload)



(Int) (Optional) If a port is defined, Scap will verify that the port is accepting TCP connections after the promote deploy stage. (Timeout defined by service_timeout)



(Int) (Optional) The amount of time to wait when checking a service_port for accepting TCP connections.

batch_size [stage]_batch_size


(Int) (Optional) Parallelism of a stage of deployment Number of hosts to execute a particular deployment stage on simultaniously. This is configurable by stage by creating a config variable: [stage]_batch_size



(Boolean) (Optional) if True, the ./scap/config-files.yaml file will be parsed, any templates defined inside will be evaluated with jinja2 and deployed.



(String) Directory in which nrpe checks are stored



(Boolean) If True, checks defined in ./scap/checks.yaml will be performed after each-stage of checkout.



(Int) (Optional) Number of tags to keep in the deployment server repo. Git appears to max-out at 999. Scap thinks 20 tags on the deployment server is quite enough.