James E. Blair | ac3c7ae | 2017-07-31 09:01:08 -0700 | [diff] [blame] | 1 | .. _glossary: |
| 2 | |
| 3 | Glossary |
| 4 | ======== |
| 5 | |
| 6 | .. glossary:: |
| 7 | :sorted: |
| 8 | |
| 9 | check |
| 10 | |
| 11 | By convention, the name of a pipeline which performs pre-merge |
| 12 | tests. Such a pipeline might be triggered by creating a new |
| 13 | change or pull request. It may run with changes which have not |
| 14 | yet seen any human review, so care must be taken in selecting |
| 15 | the kinds of jobs to run, and what resources will be available |
| 16 | to them in order to avoid misuse of the system or credential |
| 17 | compromise. |
| 18 | |
| 19 | config-project |
| 20 | |
| 21 | One of two types of projects which may be specified by the |
| 22 | administrator in the tenant config file. A config-project is |
| 23 | primarily tasked with holding configuration information and job |
| 24 | content for Zuul. Jobs which are defined in a config-project |
| 25 | are run with elevated privileges, and all Zuul configuration |
| 26 | items are available for use. It is expected that changes to |
| 27 | config-projects will undergo careful scrutiny before being |
| 28 | merged. |
| 29 | |
| 30 | gate |
| 31 | |
| 32 | By convention, the name of a pipeline which performs project |
| 33 | gating. Such a pipeline might be triggered by a core team |
| 34 | member approving a change or pull request. It should have a |
| 35 | :value:`dependent <pipeline.manager.dependent>` pipeline manager |
| 36 | so that it can combine and sequence changes as they are |
| 37 | approved. |
| 38 | |
| 39 | reporter |
| 40 | |
| 41 | A reporter is a :ref:`pipeline attribute <reporters>` which |
| 42 | describes the action performed when an item is dequeued after |
| 43 | its jobs complete. Reporters are implemented by :ref:`drivers` |
| 44 | so their actions may be quite varied. For example, a reporter |
| 45 | might leave feedback in a remote system on a proposed change, |
| 46 | send email, or store information in a database. |
| 47 | |
| 48 | untrusted-project |
| 49 | |
| 50 | One of two types of projects which may be specified by the |
| 51 | administrator in the tenant config file. An untrusted-project |
| 52 | is one whose primary focus is not to operate Zuul, but rather it |
| 53 | is one of the projects being tested or deployed. The Zuul |
| 54 | configuration language available to these projects is somewhat |
| 55 | restricted, and jobs defined in these projects run in a |
| 56 | restricted execution environment since they may be operating on |
| 57 | changes which have not yet undergone review. |