| 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 | |
| James E. Blair | 9d0b4cc | 2017-08-03 15:08:47 -0700 | [diff] [blame] | 48 | trusted execution context |
| 49 | |
| 50 | Playbooks defined in a :term:`config-project` run in the |
| 51 | *trusted* execution context. The trusted execution context has |
| 52 | access to all Ansible features, including the ability to load |
| 53 | custom Ansible modules. |
| 54 | |
| 55 | untrusted execution context |
| 56 | |
| 57 | Playbooks defined in an :term:`untrusted-project` run in the |
| 58 | *untrusted* execution context. Playbooks run in the untrusted |
| 59 | execution context are not permitted to load additional Ansible |
| 60 | modules or access files outside of the restricted environment |
| 61 | prepared for them by the executor. In addition to the |
| 62 | bubblewrap environment applied to both execution contexts, in |
| 63 | the untrusted context some standard Ansible modules are replaced |
| 64 | with versions which prohibit some actions, including attempts to |
| 65 | access files outside of the restricted execution context. These |
| 66 | redundant protections are made as part of a defense-in-depth |
| 67 | strategy. |
| 68 | |
| James E. Blair | ac3c7ae | 2017-07-31 09:01:08 -0700 | [diff] [blame] | 69 | untrusted-project |
| 70 | |
| 71 | One of two types of projects which may be specified by the |
| 72 | administrator in the tenant config file. An untrusted-project |
| 73 | is one whose primary focus is not to operate Zuul, but rather it |
| 74 | is one of the projects being tested or deployed. The Zuul |
| 75 | configuration language available to these projects is somewhat |
| 76 | restricted, and jobs defined in these projects run in a |
| 77 | restricted execution environment since they may be operating on |
| 78 | changes which have not yet undergone review. |