James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 1 | :title: Tenant Configuration |
| 2 | |
| 3 | .. _tenant-config: |
| 4 | |
| 5 | Tenant Configuration |
| 6 | ==================== |
| 7 | |
| 8 | After *zuul.conf* is configured, Zuul component servers will be able |
| 9 | to start, but a tenant configuration is required in order for Zuul to |
| 10 | perform any actions. The tenant configuration file specifies upon |
| 11 | which projects Zuul should operate. These repositories are |
| 12 | grouped into tenants. The configuration of each tenant is separate |
| 13 | from the rest (no pipelines, jobs, etc are shared between them). |
| 14 | |
| 15 | A project may appear in more than one tenant; this may be useful if |
| 16 | you wish to use common job definitions across multiple tenants. |
| 17 | |
| 18 | The tenant configuration file is specified by the *tenant_config* |
| 19 | setting in the *scheduler* section of *zuul.yaml*. It is a YAML file |
| 20 | which, like other Zuul configuration files, is a list of configuration |
| 21 | objects, though only one type of object is supported, *tenant*. |
| 22 | |
| 23 | Tenant |
| 24 | ------ |
| 25 | |
| 26 | A tenant is a collection of projects which share a Zuul |
| 27 | configuration. 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 | |
| 41 | The 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. |