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 |
Tristan Cacqueray | 82f864b | 2017-08-01 05:54:42 +0000 | [diff] [blame] | 31 | max-nodes-per-job: 5 |
Tobias Henkel | eca4620 | 2017-08-02 20:27:10 +0200 | [diff] [blame^] | 32 | exclude-unprotected-branches: false |
James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 33 | source: |
| 34 | gerrit: |
| 35 | config-projects: |
| 36 | - common-config |
| 37 | - shared-jobs: |
Tristan Cacqueray | 6256a10 | 2017-07-25 04:30:50 +0000 | [diff] [blame] | 38 | include: job |
James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 39 | untrusted-projects: |
James E. Blair | 4b42e36 | 2017-07-13 13:52:22 -0700 | [diff] [blame] | 40 | - zuul-jobs: |
| 41 | shadow: common-config |
James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 42 | - project1 |
Tobias Henkel | eca4620 | 2017-08-02 20:27:10 +0200 | [diff] [blame^] | 43 | - project2: |
| 44 | exclude-unprotected-branches: true |
James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 45 | |
| 46 | The following attributes are supported: |
| 47 | |
| 48 | **name** (required) |
| 49 | The name of the tenant. This may appear in URLs, paths, and |
| 50 | monitoring fields, and so should be restricted to URL friendly |
| 51 | characters (ASCII letters, numbers, hyphen and underscore) and you |
| 52 | should avoid changing it unless necessary. |
| 53 | |
Tristan Cacqueray | 82f864b | 2017-08-01 05:54:42 +0000 | [diff] [blame] | 54 | **max-nodes-per-job** (optional) |
| 55 | The maximum number of nodes a job can request, default to 5. |
| 56 | A '-1' value removes the limit. |
| 57 | |
Tobias Henkel | eca4620 | 2017-08-02 20:27:10 +0200 | [diff] [blame^] | 58 | **exclude-unprotected-branches** (optional) |
| 59 | When using a branch and pull model on a shared github repository there are |
| 60 | usually one or more protected branches which are gated and a dynamic number of |
| 61 | personal/feature branches which are the source for the pull requests. These |
| 62 | branches can potentially include broken zuul config and therefore break the |
| 63 | global tenant wide configuration. In order to deal with this zuul's operations |
| 64 | can be limited to the protected branches which are gated. This is a tenant |
| 65 | wide setting and can be overridden per project. If not specified, defaults |
| 66 | to ``false``. |
| 67 | |
James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 68 | **source** (required) |
| 69 | A dictionary of sources to consult for projects. A tenant may |
| 70 | contain projects from multiple sources; each of those sources must |
| 71 | be listed here, along with the projects it supports. The name of a |
| 72 | :ref:`connection<connections>` is used as the dictionary key |
| 73 | (e.g. `gerrit` in the example above), and the value is a further |
| 74 | dictionary containing the keys below. |
| 75 | |
| 76 | **config-projects** |
| 77 | A list of projects to be treated as config projects in this |
| 78 | tenant. The jobs in a config project are trusted, which means |
| 79 | they run with extra privileges, do not have their configuration |
| 80 | dynamically loaded for proposed changes, and zuul.yaml files are |
| 81 | only searched for in the master branch. |
| 82 | |
| 83 | **untrusted-projects** |
| 84 | A list of projects to be treated as untrusted in this tenant. An |
| 85 | untrusted project is the typical project operated on by Zuul. |
| 86 | Their jobs run in a more restrictive environment, they may not |
| 87 | define pipelines, their configuration dynamically changes in |
| 88 | response to proposed changes, Zuul will read configuration files |
| 89 | in all of their branches. |
| 90 | |
| 91 | Each of the projects listed may be either a simple string value, or |
| 92 | it may be a dictionary with the following keys: |
| 93 | |
| 94 | **include** |
| 95 | Normally Zuul will load all of the configuration classes |
| 96 | appropriate for the type of project (config or untrusted) in |
| 97 | question. However, if you only want to load some items, the |
| 98 | *include* attribute can be used to specify that *only* the |
| 99 | specified classes should be loaded. Supplied as a string, or a |
| 100 | list of strings. |
| 101 | |
| 102 | **exclude** |
| 103 | A list of configuration classes that should not be loaded. |
| 104 | |
James E. Blair | 4b42e36 | 2017-07-13 13:52:22 -0700 | [diff] [blame] | 105 | **shadow** |
| 106 | A list of projects which this project is permitted to shadow. |
| 107 | Normally, only one project in Zuul may contain definitions for a |
| 108 | given job. If a project earlier in the configuration defines a |
| 109 | job which a later project redefines, the later definition is |
| 110 | considered an error and is not permitted. The "shadow" attribute |
| 111 | of a project indicates that job definitions in this project which |
| 112 | conflict with the named projects should be ignored, and those in |
| 113 | the named project should be used instead. The named projects must |
| 114 | still appear earlier in the configuration. In the example above, |
| 115 | if a job definition appears in both the "common-config" and |
| 116 | "zuul-jobs" projects, the definition in "common-config" will be |
| 117 | used. |
| 118 | |
Tobias Henkel | eca4620 | 2017-08-02 20:27:10 +0200 | [diff] [blame^] | 119 | **exclude-unprotected-branches** |
| 120 | Define if unprotected github branches should be processed. Defaults to the |
| 121 | tenant wide setting of exclude-unprotected-branches. |
| 122 | |
James E. Blair | eff5a9d | 2017-06-20 00:00:37 -0700 | [diff] [blame] | 123 | The order of the projects listed in a tenant is important. A job |
| 124 | which is defined in one project may not be redefined in another |
| 125 | project; therefore, once a job appears in one project, a project |
| 126 | listed later will be unable to define a job with that name. |
| 127 | Further, some aspects of project configuration (such as the merge |
| 128 | mode) may only be set on the first appearance of a project |
| 129 | definition. |
| 130 | |
| 131 | Zuul loads the configuration from all *config-projects* in the order |
| 132 | listed, followed by all *trusted-projects* in order. |