86 lines
3.5 KiB
ReStructuredText
86 lines
3.5 KiB
ReStructuredText
.. _glossary:
|
|
|
|
Glossary
|
|
========
|
|
|
|
.. glossary::
|
|
:sorted:
|
|
|
|
base job
|
|
|
|
A job with no parent. A base job may only be defined in a
|
|
:term:`config-project`. Multiple base jobs may be defined, but
|
|
each tenant has a single default job which will be used as the
|
|
parent of any job which does not specify one explicitly.
|
|
|
|
check
|
|
|
|
By convention, the name of a pipeline which performs pre-merge
|
|
tests. Such a pipeline might be triggered by creating a new
|
|
change or pull request. It may run with changes which have not
|
|
yet seen any human review, so care must be taken in selecting
|
|
the kinds of jobs to run, and what resources will be available
|
|
to them in order to avoid misuse of the system or credential
|
|
compromise.
|
|
|
|
config-project
|
|
|
|
One of two types of projects which may be specified by the
|
|
administrator in the tenant config file. A config-project is
|
|
primarily tasked with holding configuration information and job
|
|
content for Zuul. Jobs which are defined in a config-project
|
|
are run with elevated privileges, and all Zuul configuration
|
|
items are available for use. It is expected that changes to
|
|
config-projects will undergo careful scrutiny before being
|
|
merged.
|
|
|
|
gate
|
|
|
|
By convention, the name of a pipeline which performs project
|
|
gating. Such a pipeline might be triggered by a core team
|
|
member approving a change or pull request. It should have a
|
|
:value:`dependent <pipeline.manager.dependent>` pipeline manager
|
|
so that it can combine and sequence changes as they are
|
|
approved.
|
|
|
|
reporter
|
|
|
|
A reporter is a :ref:`pipeline attribute <reporters>` which
|
|
describes the action performed when an item is dequeued after
|
|
its jobs complete. Reporters are implemented by :ref:`drivers`
|
|
so their actions may be quite varied. For example, a reporter
|
|
might leave feedback in a remote system on a proposed change,
|
|
send email, or store information in a database.
|
|
|
|
trusted execution context
|
|
|
|
Playbooks defined in a :term:`config-project` run in the
|
|
*trusted* execution context. The trusted execution context has
|
|
access to all Ansible features, including the ability to load
|
|
custom Ansible modules.
|
|
|
|
untrusted execution context
|
|
|
|
Playbooks defined in an :term:`untrusted-project` run in the
|
|
*untrusted* execution context. Playbooks run in the untrusted
|
|
execution context are not permitted to load additional Ansible
|
|
modules or access files outside of the restricted environment
|
|
prepared for them by the executor. In addition to the
|
|
bubblewrap environment applied to both execution contexts, in
|
|
the untrusted context some standard Ansible modules are replaced
|
|
with versions which prohibit some actions, including attempts to
|
|
access files outside of the restricted execution context. These
|
|
redundant protections are made as part of a defense-in-depth
|
|
strategy.
|
|
|
|
untrusted-project
|
|
|
|
One of two types of projects which may be specified by the
|
|
administrator in the tenant config file. An untrusted-project
|
|
is one whose primary focus is not to operate Zuul, but rather it
|
|
is one of the projects being tested or deployed. The Zuul
|
|
configuration language available to these projects is somewhat
|
|
restricted, and jobs defined in these projects run in a
|
|
restricted execution environment since they may be operating on
|
|
changes which have not yet undergone review.
|