blob: 88723974fe9f36d192b60dcdd1608c6e36bf0e6c [file] [log] [blame]
James E. Blaireff5a9d2017-06-20 00:00:37 -07001:title: Tenant Configuration
2
3.. _tenant-config:
4
5Tenant Configuration
6====================
7
8After *zuul.conf* is configured, Zuul component servers will be able
9to start, but a tenant configuration is required in order for Zuul to
10perform any actions. The tenant configuration file specifies upon
11which projects Zuul should operate. These repositories are
12grouped into tenants. The configuration of each tenant is separate
13from the rest (no pipelines, jobs, etc are shared between them).
14
15A project may appear in more than one tenant; this may be useful if
16you wish to use common job definitions across multiple tenants.
17
18The tenant configuration file is specified by the *tenant_config*
19setting in the *scheduler* section of *zuul.yaml*. It is a YAML file
20which, like other Zuul configuration files, is a list of configuration
21objects, though only one type of object is supported, *tenant*.
22
23Tenant
24------
25
26A tenant is a collection of projects which share a Zuul
27configuration. An example tenant definition is::
28
29 - tenant:
30 name: my-tenant
31 source:
32 gerrit:
33 config-projects:
34 - common-config
35 - shared-jobs:
36 include: jobs
37 untrusted-projects:
38 - project1
39 - project2
40
41The following attributes are supported:
42
43**name** (required)
44 The name of the tenant. This may appear in URLs, paths, and
45 monitoring fields, and so should be restricted to URL friendly
46 characters (ASCII letters, numbers, hyphen and underscore) and you
47 should avoid changing it unless necessary.
48
49**source** (required)
50 A dictionary of sources to consult for projects. A tenant may
51 contain projects from multiple sources; each of those sources must
52 be listed here, along with the projects it supports. The name of a
53 :ref:`connection<connections>` is used as the dictionary key
54 (e.g. `gerrit` in the example above), and the value is a further
55 dictionary containing the keys below.
56
57 **config-projects**
58 A list of projects to be treated as config projects in this
59 tenant. The jobs in a config project are trusted, which means
60 they run with extra privileges, do not have their configuration
61 dynamically loaded for proposed changes, and zuul.yaml files are
62 only searched for in the master branch.
63
64 **untrusted-projects**
65 A list of projects to be treated as untrusted in this tenant. An
66 untrusted project is the typical project operated on by Zuul.
67 Their jobs run in a more restrictive environment, they may not
68 define pipelines, their configuration dynamically changes in
69 response to proposed changes, Zuul will read configuration files
70 in all of their branches.
71
72 Each of the projects listed may be either a simple string value, or
73 it may be a dictionary with the following keys:
74
75 **include**
76 Normally Zuul will load all of the configuration classes
77 appropriate for the type of project (config or untrusted) in
78 question. However, if you only want to load some items, the
79 *include* attribute can be used to specify that *only* the
80 specified classes should be loaded. Supplied as a string, or a
81 list of strings.
82
83 **exclude**
84 A list of configuration classes that should not be loaded.
85
86 The order of the projects listed in a tenant is important. A job
87 which is defined in one project may not be redefined in another
88 project; therefore, once a job appears in one project, a project
89 listed later will be unable to define a job with that name.
90 Further, some aspects of project configuration (such as the merge
91 mode) may only be set on the first appearance of a project
92 definition.
93
94 Zuul loads the configuration from all *config-projects* in the order
95 listed, followed by all *trusted-projects* in order.