James E. Blair
5 years ago
995 changed files with 58394 additions and 19548 deletions
@ -1,4 +1,4 @@
|
||||
[DEFAULT] |
||||
test_command=OS_LOG_LEVEL=${OS_LOG_LEVEL:-INFO} OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} OS_LOG_DEFAULTS=${OS_LOG_DEFAULTS:-""} ${PYTHON:-python} -m subunit.run discover -t ./ tests $LISTOPT $IDOPTION |
||||
test_command=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} OS_LOG_CAPTURE=${OS_LOG_CAPTURE:-1} OS_LOG_DEFAULTS=${OS_LOG_DEFAULTS:-""} ${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./tests/unit} $LISTOPT $IDOPTION |
||||
test_id_option=--load-list $IDFILE |
||||
test_list_option=--list |
||||
|
||||
@ -1,14 +1,64 @@
|
||||
- nodeset: |
||||
name: zuul-functional-temp-master |
||||
nodes: |
||||
- name: controller |
||||
label: ubuntu-xenial |
||||
- name: node1 |
||||
label: ubuntu-xenial |
||||
- name: node2 |
||||
label: ubuntu-xenial |
||||
groups: |
||||
- name: node |
||||
nodes: |
||||
- node1 |
||||
- node2 |
||||
|
||||
- job: |
||||
name: zuul-stream-functional |
||||
parent: multinode |
||||
nodeset: zuul-functional-temp-master |
||||
pre-run: playbooks/zuul-stream/pre.yaml |
||||
run: playbooks/zuul-stream/functional.yaml |
||||
post-run: |
||||
- playbooks/zuul-stream/post.yaml |
||||
- playbooks/zuul-stream/post-ara.yaml |
||||
required-projects: |
||||
- openstack/ara |
||||
files: |
||||
- zuul/ansible/callback/.* |
||||
- playbooks/zuul-stream/.* |
||||
|
||||
- project: |
||||
name: openstack-infra/zuul |
||||
check: |
||||
jobs: |
||||
- tox-docs |
||||
- tox-cover: |
||||
voting: false |
||||
- build-openstack-sphinx-docs: |
||||
irrelevant-files: |
||||
- zuul/cmd/migrate.py |
||||
- playbooks/zuul-migrate/.* |
||||
vars: |
||||
sphinx_python: python3 |
||||
- tox-pep8 |
||||
- tox-py27 |
||||
- tox-py35: |
||||
irrelevant-files: |
||||
- zuul/cmd/migrate.py |
||||
- playbooks/zuul-migrate/.* |
||||
- zuul-stream-functional |
||||
gate: |
||||
jobs: |
||||
- tox-docs |
||||
- build-openstack-sphinx-docs: |
||||
irrelevant-files: |
||||
- zuul/cmd/migrate.py |
||||
- playbooks/zuul-migrate/.* |
||||
vars: |
||||
sphinx_python: python3 |
||||
- tox-pep8 |
||||
- tox-py27 |
||||
- tox-py35: |
||||
irrelevant-files: |
||||
- zuul/cmd/migrate.py |
||||
- playbooks/zuul-migrate/.* |
||||
- zuul-stream-functional |
||||
post: |
||||
jobs: |
||||
- publish-openstack-sphinx-docs-infra-python3 |
||||
- publish-openstack-python-branch-tarball |
||||
|
||||
@ -0,0 +1,115 @@
|
||||
:title: Zuul Client |
||||
|
||||
Zuul Client |
||||
=========== |
||||
|
||||
Zuul includes a simple command line client that may be used by |
||||
administrators to affect Zuul's behavior while running. It must be |
||||
run on a host that has access to the Gearman server (e.g., locally on |
||||
the Zuul host). |
||||
|
||||
Configuration |
||||
------------- |
||||
|
||||
The client uses the same zuul.conf file as the server, and will look |
||||
for it in the same locations if not specified on the command line. |
||||
|
||||
Usage |
||||
----- |
||||
The general options that apply to all subcommands are: |
||||
|
||||
.. program-output:: zuul --help |
||||
|
||||
The following subcommands are supported: |
||||
|
||||
Autohold |
||||
^^^^^^^^ |
||||
.. program-output:: zuul autohold --help |
||||
|
||||
Example:: |
||||
|
||||
zuul autohold --tenant openstack --project example_project --job example_job --reason "reason text" --count 1 |
||||
|
||||
Enqueue |
||||
^^^^^^^ |
||||
.. program-output:: zuul enqueue --help |
||||
|
||||
Example:: |
||||
|
||||
zuul enqueue --tenant openstack --trigger gerrit --pipeline check --project example_project --change 12345,1 |
||||
|
||||
Note that the format of change id is <number>,<patchset>. |
||||
|
||||
Enqueue-ref |
||||
^^^^^^^^^^^ |
||||
|
||||
.. program-output:: zuul enqueue-ref --help |
||||
|
||||
This command is provided to manually simulate a trigger from an |
||||
external source. It can be useful for testing or replaying a trigger |
||||
that is difficult or impossible to recreate at the source. The |
||||
arguments to ``enqueue-ref`` will vary depending on the source and |
||||
type of trigger. Some familiarity with the arguments emitted by |
||||
``gerrit`` `update hooks |
||||
<https://gerrit-review.googlesource.com/admin/projects/plugins/hooks>`__ |
||||
such as ``patchset-created`` and ``ref-updated`` is recommended. Some |
||||
examples of common operations are provided below. |
||||
|
||||
Manual enqueue examples |
||||
*********************** |
||||
|
||||
It is common to have a ``release`` pipeline that listens for new tags |
||||
coming from ``gerrit`` and performs a range of code packaging jobs. |
||||
If there is an unexpected issue in the release jobs, the same tag can |
||||
not be recreated in ``gerrit`` and the user must either tag a new |
||||
release or request a manual re-triggering of the jobs. To re-trigger |
||||
the jobs, pass the failed tag as the ``ref`` argument and set |
||||
``newrev`` to the change associated with the tag in the project |
||||
repository (i.e. what you see from ``git show X.Y.Z``):: |
||||
|
||||
zuul enqueue-ref --tenant openstack --trigger gerrit --pipeline release --project openstack/example_project --ref refs/tags/X.Y.Z --newrev abc123... |
||||
|
||||
The command can also be used asynchronosly trigger a job in a |
||||
``periodic`` pipeline that would usually be run at a specific time by |
||||
the ``timer`` driver. For example, the following command would |
||||
trigger the ``periodic`` jobs against the current ``master`` branch |
||||
top-of-tree for a project:: |
||||
|
||||
zuul enqueue-ref --tenant openstack --trigger timer --pipeline periodic --project openstack/example_project --ref refs/heads/master |
||||
|
||||
Another common pipeline is a ``post`` queue listening for ``gerrit`` |
||||
merge results. Triggering here is slightly more complicated as you |
||||
wish to recreate the full ``ref-updated`` event from ``gerrit``. For |
||||
a new commit on ``master``, the gerrit ``ref-updated`` trigger |
||||
expresses "reset ``refs/heads/master`` for the project from ``oldrev`` |
||||
to ``newrev``" (``newrev`` being the committed change). Thus to |
||||
replay the event, you could ``git log`` in the project and take the |
||||
current ``HEAD`` and the prior change, then enqueue the event:: |
||||
|
||||
NEW_REF=$(git rev-parse HEAD) |
||||
OLD_REF=$(git rev-parse HEAD~1) |
||||
|
||||
zuul enqueue-ref --tenant openstack --trigger gerrit --pipeline post --project openstack/example_project --ref refs/heads/master --newrev $NEW_REF --oldrev $OLD_REF |
||||
|
||||
Note that zero values for ``oldrev`` and ``newrev`` can indicate |
||||
branch creation and deletion; the source code is the best reference |
||||
for these more advanced operations. |
||||
|
||||
|
||||
Promote |
||||
^^^^^^^ |
||||
.. program-output:: zuul promote --help |
||||
|
||||
Example:: |
||||
|
||||
zuul promote --tenant openstack --pipeline check --changes 12345,1 13336,3 |
||||
|
||||
Note that the format of changes id is <number>,<patchset>. |
||||
|
||||
Show |
||||
^^^^ |
||||
.. program-output:: zuul show --help |
||||
|
||||
Example:: |
||||
|
||||
zuul show running-jobs |
||||
@ -0,0 +1,739 @@
|
||||
:title: Components |
||||
|
||||
.. _components: |
||||
|
||||
Components |
||||
========== |
||||
|
||||
Zuul is a distributed system consisting of several components, each of |
||||
which is described below. |
||||
|
||||
.. graphviz:: |
||||
:align: center |
||||
|
||||
graph { |
||||
node [shape=box] |
||||
Gearman [shape=ellipse] |
||||
Gerrit [fontcolor=grey] |
||||
Zookeeper [shape=ellipse] |
||||
Nodepool |
||||
GitHub [fontcolor=grey] |
||||
|
||||
Merger -- Gearman |
||||
Executor -- Gearman |
||||
Web -- Gearman |
||||
|
||||
Gearman -- Scheduler; |
||||
Scheduler -- Gerrit; |
||||
Scheduler -- Zookeeper; |
||||
Zookeeper -- Nodepool; |
||||
Scheduler -- GitHub; |
||||
} |
||||
|
||||
Each of the Zuul processes may run on the same host, or different |
||||
hosts. Within Zuul, the components communicate with the scheduler via |
||||
the Gearman protocol, so each Zuul component needs to be able to |
||||
connect to the host running the Gearman server (the scheduler has a |
||||
built-in Gearman server which is recommended) on the Gearman port -- |
||||
TCP port 4730 by default. |
||||
|
||||
The Zuul scheduler communicates with Nodepool via the ZooKeeper |
||||
protocol. Nodepool requires an external ZooKeeper cluster, and the |
||||
Zuul scheduler needs to be able to connect to the hosts in that |
||||
cluster on TCP port 2181. |
||||
|
||||
Both the Nodepool launchers and Zuul executors need to be able to |
||||
communicate with the hosts which nodepool provides. If these are on |
||||
private networks, the Executors will need to be able to route traffic |
||||
to them. |
||||
|
||||
If statsd is enabled, every service needs to be able to emit data to |
||||
statsd. Statsd can be configured to run on each host and forward |
||||
data, or services may emit to a centralized statsd collector. Statsd |
||||
listens on UDP port 8125 by default. |
||||
|
||||
All Zuul processes read the ``/etc/zuul/zuul.conf`` file (an alternate |
||||
location may be supplied on the command line) which uses an INI file |
||||
syntax. Each component may have its own configuration file, though |
||||
you may find it simpler to use the same file for all components. |
||||
|
||||
An example ``zuul.conf``: |
||||
|
||||
.. code-block:: ini |
||||
|
||||
[gearman] |
||||
server=localhost |
||||
|
||||
[gearman_server] |
||||
start=true |
||||
log_config=/etc/zuul/gearman-logging.yaml |
||||
|
||||
[zookeeper] |
||||
hosts=zk1.example.com,zk2.example.com,zk3.example.com |
||||
|
||||
[webapp] |
||||
status_url=https://zuul.example.com/status |
||||
|
||||
[scheduler] |
||||
log_config=/etc/zuul/scheduler-logging.yaml |
||||
|
||||
A minimal Zuul system may consist of a :ref:`scheduler` and |
||||
:ref:`executor` both running on the same host. Larger installations |
||||
should consider running multiple executors, each on a dedicated host, |
||||
and running mergers on dedicated hosts as well. |
||||
|
||||
Common |
||||
------ |
||||
|
||||
The following applies to all Zuul components. |
||||
|
||||
Configuration |
||||
~~~~~~~~~~~~~ |
||||
|
||||
The following sections of ``zuul.conf`` are used by all Zuul components: |
||||
|
||||
|
||||
.. attr:: gearman |
||||
|
||||
Client connection information for Gearman. |
||||
|
||||
.. attr:: server |
||||
:required: |
||||
|
||||
Hostname or IP address of the Gearman server. |
||||
|
||||
.. attr:: port |
||||
:default: 4730 |
||||
|
||||
Port on which the Gearman server is listening. |
||||
|
||||
.. attr:: ssl_ca |
||||
|
||||
An openssl file containing a set of concatenated “certification |
||||
authority” certificates in PEM formet. |
||||
|
||||
.. attr:: ssl_cert |
||||
|
||||
An openssl file containing the client public certificate in PEM format. |
||||
|
||||
.. attr:: ssl_key |
||||
|
||||
An openssl file containing the client private key in PEM format. |
||||
|
||||
.. attr:: statsd |
||||
|
||||
Information about the optional statsd server. If the ``statsd`` |
||||
python module is installed and this section is configured, |
||||
statistics will be reported to statsd. See :ref:`statsd` for more |
||||
information. |
||||
|
||||
.. attr:: server |
||||
|
||||
Hostname or IP address of the statsd server. |
||||
|
||||
.. attr:: port |
||||
:default: 8125 |
||||
|
||||
The UDP port on which the statsd server is listening. |
||||
|
||||
.. attr:: prefix |
||||
|
||||
If present, this will be prefixed to all of the keys before |
||||
transmitting to the statsd server. |
||||
|
||||
.. NOTE: this is a white lie at this point, since only the scheduler |
||||
uses this, however, we expect other components to use it later, so |
||||
it's reasonable for admins to plan for this now. |
||||
|
||||
.. attr:: zookeeper |
||||
|
||||
Client connection information for ZooKeeper |
||||
|
||||
.. attr:: hosts |
||||
:required: |
||||
|
||||
A list of zookeeper hosts for Zuul to use when communicating |
||||
with Nodepool. |
||||
|
||||
.. attr:: session_timeout |
||||
:default: 10.0 |
||||
|
||||
The ZooKeeper session timeout, in seconds. |
||||
|
||||
|
||||
.. _scheduler: |
||||
|
||||
Scheduler |
||||
--------- |
||||
|
||||
The scheduler is the primary component of Zuul. The scheduler is not |
||||
a scalable component; one, and only one, scheduler must be running at |
||||
all times for Zuul to be operational. It receives events from any |
||||
connections to remote systems which have been configured, enqueues |
||||
items into pipelines, distributes jobs to executors, and reports |
||||
results. |
||||
|
||||
The scheduler includes a Gearman server which is used to communicate |
||||
with other components of Zuul. It is possible to use an external |
||||
Gearman server, but the built-in server is well-tested and |
||||
recommended. If the built-in server is used, other Zuul hosts will |
||||
need to be able to connect to the scheduler on the Gearman port, TCP |
||||
port 4730. It is also strongly recommended to use SSL certs with |
||||
Gearman, as secrets are transferred from the scheduler to executors |
||||
over this link. |
||||
|
||||
The scheduler must be able to connect to the ZooKeeper cluster used by |
||||
Nodepool in order to request nodes. It does not need to connect |
||||
directly to the nodes themselves, however -- that function is handled |
||||
by the Executors. |
||||
|
||||
It must also be able to connect to any services for which connections |
||||
are configured (Gerrit, GitHub, etc). |
||||
|
||||
Configuration |
||||
~~~~~~~~~~~~~ |
||||
|
||||
The following sections of ``zuul.conf`` are used by the scheduler: |
||||
|
||||
|
||||
.. attr:: gearman_server |
||||
|
||||
The builtin gearman server. Zuul can fork a gearman process from |
||||
itself rather than connecting to an external one. |
||||
|
||||
.. attr:: start |
||||
:default: false |
||||
|
||||
Whether to start the internal Gearman server. |
||||
|
||||
.. attr:: listen_address |
||||
:default: all addresses |
||||
|
||||
IP address or domain name on which to listen. |
||||
|
||||
.. attr:: port |
||||
:default: 4730 |
||||
|
||||
TCP port on which to listen. |
||||
|
||||
.. attr:: log_config |
||||
|
||||
Path to log config file for internal Gearman server. |
||||
|
||||
.. attr:: ssl_ca |
||||
|
||||
An openssl file containing a set of concatenated “certification |
||||
authority” certificates in PEM formet. |
||||
|
||||
.. attr:: ssl_cert |
||||
|
||||
An openssl file containing the server public certificate in PEM |
||||
format. |
||||
|
||||
.. attr:: ssl_key |
||||
|
||||
An openssl file containing the server private key in PEM format. |
||||
|
||||
.. attr:: webapp |
||||
|
||||
.. attr:: listen_address |
||||
:default: all addresses |
||||
|
||||
IP address or domain name on which to listen. |
||||
|
||||
.. attr:: port |
||||
:default: 8001 |
||||
|
||||
Port on which the webapp is listening. |
||||
|
||||
.. attr:: status_expiry |
||||
:default: 1 |
||||
|
||||
Zuul will cache the status.json file for this many seconds. |
||||
|
||||
.. attr:: status_url |
||||
|
||||
URL that will be posted in Zuul comments made to changes when |
||||
starting jobs for a change. |
||||
|
||||
.. TODO: is this effectively required? |
||||
|
||||
.. attr:: scheduler |
||||
|
||||
.. attr:: command_socket |
||||
:default: /var/lib/zuul/scheduler.socket |
||||
|
||||
Path to command socket file for the scheduler process. |
||||
|
||||
.. attr:: tenant_config |
||||
:required: |
||||
|
||||
Path to :ref:`tenant-config` file. |
||||
|
||||
.. attr:: log_config |
||||
|
||||
Path to log config file. |
||||
|
||||
.. attr:: pidfile |
||||
:default: /var/run/zuul-schedurecr/zuul-scheduler.pid |
||||
|
||||
Path to PID lock file. |
||||
|
||||
.. attr:: state_dir |
||||
:default: /var/lib/zuul |
||||
|
||||
Path to directory in which Zuul should save its state. |
||||
|
||||
Operation |
||||
~~~~~~~~~ |
||||
|
||||
To start the scheduler, run ``zuul-scheduler``. To stop it, kill the |
||||
PID which was saved in the pidfile specified in the configuration. |
||||
|
||||
Most of Zuul's configuration is automatically updated as changes to |
||||
the repositories which contain it are merged. However, Zuul must be |
||||
explicitly notified of changes to the tenant config file, since it is |
||||
not read from a git repository. To do so, send the scheduler PID |
||||
(saved in the pidfile specified in the configuration) a `SIGHUP` |
||||
signal. |
||||
|
||||
Merger |
||||
------ |
||||
|
||||
Mergers are an optional Zuul service; they are not required for Zuul |
||||
to operate, but some high volume sites may benefit from running them. |
||||
Zuul performs quite a lot of git operations in the course of its work. |
||||
Each change that is to be tested must be speculatively merged with the |
||||
current state of its target branch to ensure that it can merge, and to |
||||
ensure that the tests that Zuul perform accurately represent the |
||||
outcome of merging the change. Because Zuul's configuration is stored |
||||
in the git repos it interacts with, and is dynamically evaluated, Zuul |
||||
often needs to perform a speculative merge in order to determine |
||||
whether it needs to perform any further actions. |
||||
|
||||
All of these git operations add up, and while Zuul executors can also |
||||
perform them, large numbers may impact their ability to run jobs. |
||||
Therefore, administrators may wish to run standalone mergers in order |
||||
to reduce the load on executors. |
||||
|
||||
Mergers need to be able to connect to the Gearman server (usually the |
||||
scheduler host) as well as any services for which connections are |
||||
configured (Gerrit, GitHub, etc). |
||||
|
||||
Configuration |
||||
~~~~~~~~~~~~~ |
||||
|
||||
The following section of ``zuul.conf`` is used by the merger: |
||||
|
||||
.. attr:: merger |
||||
|
||||
.. attr:: command_socket |
||||
:default: /var/lib/zuul/merger.socket |
||||
|
||||
Path to command socket file for the merger process. |
||||
|
||||
.. attr:: git_dir |
||||
|
||||
Directory in which Zuul should clone git repositories. |
||||
|
||||
.. attr:: git_http_low_speed_limit |
||||
:default: 1000 |
||||
|
||||
If the HTTP transfer speed is less then git_http_low_speed_limit for |
||||
longer then git_http_low_speed_time, the transfer is aborted. |
||||
|
||||
Value in bytes, setting to 0 will disable. |
||||
|
||||
.. attr:: git_http_low_speed_time |
||||
:default: 30 |
||||
|
||||
If the HTTP transfer speed is less then git_http_low_speed_limit for |
||||
longer then git_http_low_speed_time, the transfer is aborted. |
||||
|
||||
Value in seconds, setting to 0 will disable. |
||||
|
||||
.. attr:: git_user_email |
||||
|
||||
Value to pass to `git config user.email |
||||
<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>`_. |
||||
|
||||
.. attr:: git_user_name |
||||
|
||||
Value to pass to `git config user.name |
||||
<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>`_. |
||||
|
||||
.. attr:: log_config |
||||
|
||||
Path to log config file for the merger process. |
||||
|
||||
.. attr:: pidfile |
||||
:default: /var/run/zuul-merger/zuul-merger.pid |
||||
|
||||
Path to PID lock file for the merger process. |
||||
|
||||
Operation |
||||
~~~~~~~~~ |
||||
|
||||
To start the merger, run ``zuul-merger``. To stop it, kill the |
||||
PID which was saved in the pidfile specified in the configuration. |
||||
|
||||
.. _executor: |
||||
|
||||
Executor |
||||
-------- |
||||
|
||||
Executors are responsible for running jobs. At the start of each job, |
||||
an executor prepares an environment in which to run Ansible which |
||||
contains all of the git repositories specified by the job with all |
||||
dependent changes merged into their appropriate branches. The branch |
||||
corresponding to the proposed change will be checked out (in all |
||||
projects, if it exists). Any roles specified by the job will also be |
||||
present (also with dependent changes merged, if appropriate) and added |
||||
to the Ansible role path. The executor also prepares an Ansible |
||||
inventory file with all of the nodes requested by the job. |
||||
|
||||
The executor also contains a merger. This is used by the executor to |
||||
prepare the git repositories used by jobs, but is also available to |
||||
perform any tasks normally performed by standalone mergers. Because |
||||
the executor performs both roles, small Zuul installations may not |
||||
need to run standalone mergers. |
||||
|
||||
Executors need to be able to connect to the Gearman server (usually |
||||
the scheduler host), any services for which connections are configured |
||||
(Gerrit, GitHub, etc), as well as directly to the hosts which Nodepool |
||||
provides. |
||||
|
||||
Trusted and Untrusted Playbooks |
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
||||
|
||||
The executor runs playbooks in one of two execution contexts depending |
||||
on whether the project containing the playbook is a |
||||
:term:`config-project` or an :term:`untrusted-project`. If the |
||||
playbook is in a config project, the executor runs the playbook in the |
||||
*trusted* execution context, otherwise, it is run in the *untrusted* |
||||
execution context. |
||||
|
||||
Both execution contexts use `bubblewrap`_ [#nullwrap]_ to create a |
||||
namespace to ensure that playbook executions are isolated and are unable |
||||
to access files outside of a restricted environment. The administrator |
||||
may configure additional local directories on the executor to be made |
||||
available to the restricted environment. |
||||
|
||||
The trusted execution context has access to all Ansible features, |
||||
including the ability to load custom Ansible modules. Needless to |
||||
say, extra scrutiny should be given to code that runs in a trusted |
||||
context as it could be used to compromise other jobs running on the |
||||
executor, or the executor itself, especially if the administrator has |
||||
granted additional access through bubblewrap, or a method of escaping |
||||
the restricted environment created by bubblewrap is found. |
||||
|
||||
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. |
||||
|
||||
.. _bubblewrap: https://github.com/projectatomic/bubblewrap |
||||
.. [#nullwrap] Unless one has set execution_wrapper to nullwrap in the |
||||
executor configuration. |
||||
|
||||
Configuration |
||||
~~~~~~~~~~~~~ |
||||
|
||||
The following sections of ``zuul.conf`` are used by the executor: |
||||
|
||||
.. attr:: executor |
||||
|
||||
.. attr:: command_socket |
||||
:default: /var/lib/zuul/executor.socket |
||||
|
||||
Path to command socket file for the executor process. |
||||
|
||||
.. attr:: finger_port |
||||
:default: 7900 |
||||
|
||||
Port to use for finger log streamer. |
||||
|
||||
.. attr:: git_dir |
||||
:default: /var/lib/zuul/git |
||||
|
||||
Directory that Zuul should clone local git repositories to. The |
||||
executor keeps a local copy of every git repository it works |
||||
with to speed operations and perform speculative merging. |
||||
|
||||
This should be on the same filesystem as |
||||
:attr:`executor.job_dir` so that when git repos are cloned into |
||||
the job workspaces, they can be hard-linked to the local git |
||||
cache. |
||||
|
||||
.. attr:: job_dir |
||||
:default: /tmp |
||||
|
||||
Directory that Zuul should use to hold temporary job directories. |
||||
When each job is run, a new entry will be created under this |
||||
directory to hold the configuration and scratch workspace for |
||||
that job. It will be deleted at the end of the job (unless the |
||||
`--keep-jobdir` command line option is specified). |
||||
|
||||
This should be on the same filesystem as :attr:`executor.git_dir` |
||||
so that when git repos are cloned into the job workspaces, they |
||||
can be hard-linked to the local git cache. |
||||
|
||||
.. attr:: log_config |
||||
|
||||
Path to log config file for the executor process. |
||||
|
||||
.. attr:: pidfile |
||||
:default: /var/run/zuul-executor/zuul-executor.pid |
||||
|
||||
Path to PID lock file for the executor process. |
||||
|
||||
.. attr:: private_key_file |
||||
:default: ~/.ssh/id_rsa |
||||
|
||||
SSH private key file to be used when logging into worker nodes. |
||||
|
||||
.. _admin_sitewide_variables: |
||||
|
||||
.. attr:: variables |
||||
|
||||
Path to an Ansible variables file to supply site-wide variables. |
||||
This should be a YAML-formatted file consisting of a single |
||||
dictionary. The contents will be made available to all jobs as |
||||
Ansible variables. These variables take precedence over all |
||||
other forms (job variables and secrets). Care should be taken |
||||
when naming these variables to avoid potential collisions with |
||||
those used by jobs. Prefixing variable names with a |
||||
site-specific identifier is recommended. The default is not to |
||||
add any site-wide variables. See the :ref:`User's Guide |
||||
<user_sitewide_variables>` for more information. |
||||
|
||||
.. attr:: disk_limit_per_job |
||||
:default: 250 |
||||
|
||||
This integer is the maximum number of megabytes that any one job |
||||
is allowed to consume on disk while it is running. If a job's |
||||
scratch space has more than this much space consumed, it will be |
||||
aborted. |
||||
|
||||
.. attr:: trusted_ro_paths |
||||
|
||||
List of paths, separated by ``:`` to read-only bind mount into |
||||
trusted bubblewrap contexts. |
||||
|
||||
.. attr:: trusted_rw_paths |
||||
|
||||
List of paths, separated by ``:`` to read-write bind mount into |
||||
trusted bubblewrap contexts. |
||||
|
||||
.. attr:: untrusted_ro_paths |
||||
|
||||
List of paths, separated by ``:`` to read-only bind mount into |
||||
untrusted bubblewrap contexts. |
||||
|
||||
.. attr:: untrusted_rw_paths |
||||
|
||||
List of paths, separated by ``:`` to read-write bind mount into |
||||
untrusted bubblewrap contexts. |
||||
|
||||
.. attr:: execution_wrapper |
||||
:default: bubblewrap |
||||
|
||||
Name of the execution wrapper to use when executing |
||||
`ansible-playbook`. The default, `bubblewrap` is recommended for |
||||
all installations. |
||||
|
||||
There is also a `nullwrap` driver for situations where one wants |
||||
to run Zuul without access to bubblewrap or in such a way that |
||||
bubblewrap may interfere with the jobs themselves. However, |
||||
`nullwrap` is considered unsafe, as `bubblewrap` provides |
||||
significant protections against malicious users and accidental |
||||
breakage in playbooks. As such, `nullwrap` is not recommended |
||||
for use in production. |
||||
|
||||
This option, and thus, `nullwrap`, may be removed in the future. |
||||
`bubblewrap` has become integral to securely operating Zuul. If you |
||||
have a valid use case for it, we encourage you to let us know. |
||||
|
||||
.. attr:: load_multiplier |
||||
:default: 2.5 |
||||
|
||||
When an executor host gets too busy, the system may suffer |
||||
timeouts and other ill effects. The executor will stop accepting |
||||
more than 1 job at a time until load has lowered below a safe |
||||
level. This level is determined by multiplying the number of |
||||
CPU's by `load_multiplier`. |
||||
|
||||
So for example, if the system has 2 CPUs, and load_multiplier |
||||
is 2.5, the safe load for the system is 5.00. Any time the |
||||
system load average is over 5.00, the executor will quit |
||||
accepting multiple jobs at one time. |
||||
|
||||
The executor will observe system load and determine whether |
||||
to accept more jobs every 30 seconds. |
||||
|
||||
.. attr:: hostname |
||||
:default: hostname of the server |
||||
|
||||
The executor needs to know its hostname under which it is reachable by |
||||
zuul-web. Otherwise live console log streaming doesn't work. In most cases |
||||
This is automatically detected correctly. But when running in environments |
||||
where it cannot determine its hostname correctly this can be overridden |
||||
here. |
||||
|
||||
.. attr:: merger |
||||
|
||||
.. attr:: git_user_email |
||||
|
||||
Value to pass to `git config user.email |
||||
<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>`_. |
||||
|
||||
.. attr:: git_user_name |
||||
|
||||
Value to pass to `git config user.name |
||||
<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>`_. |
||||
|
||||
Operation |
||||
~~~~~~~~~ |
||||
|
||||
To start the executor, run ``zuul-executor``. |
||||
|
||||
There are several commands which can be run to control the executor's |
||||
behavior once it is running. |
||||
|
||||
To stop the executor immediately, aborting all jobs (they may be |
||||
relaunched according to their retry policy), run ``zuul-executor |
||||
stop``. |
||||
|
||||
To request that the executor stop executing new jobs and exit when all |
||||
currently running jobs have completed, run ``zuul-executor graceful``. |
||||
|
||||
To enable or disable running Ansible in verbose mode (with the |
||||
``-vvv`` argument to ansible-playbook) run ``zuul-executor verbose`` |
||||
and ``zuul-executor unverbose``. |
||||
|
||||
Web Server |
||||
---------- |
||||
|
||||
The Zuul web server currently acts as a websocket interface to live log |
||||
streaming. Eventually, it will serve as the single process handling all |
||||
HTTP interactions with Zuul. |
||||
|
||||
Web servers need to be able to connect to the Gearman server (usually |
||||
the scheduler host). If the SQL reporter is used, they need to be |
||||
able to connect to the database it reports to in order to support the |
||||
dashboard. If a GitHub connection is configured, they need to be |
||||
reachable by GitHub so they may receive notifications. |
||||
|
||||
Configuration |
||||
~~~~~~~~~~~~~ |
||||
|
||||
In addition to the common configuration sections, the following |
||||
sections of ``zuul.conf`` are used by the web server: |
||||
|
||||
.. attr:: web |
||||
|
||||
.. attr:: listen_address |
||||
:default: 127.0.0.1 |
||||
|
||||
IP address or domain name on which to listen. |
||||
|
||||
.. attr:: log_config |
||||
|
||||
Path to log config file for the web server process. |
||||
|
||||
.. attr:: pidfile |
||||
:default: /var/run/zuul-web/zuul-web.pid |
||||
|
||||
Path to PID lock file for the web server process. |
||||
|
||||
.. attr:: port |
||||
:default: 9000 |
||||
|
||||
Port to use for web server process. |
||||
|
||||
.. attr:: websocket_url |
||||
|
||||
Base URL on which the websocket service is exposed, if different |
||||
than the base URL of the web app. |
||||
|
||||
.. attr:: static_cache_expiry |
||||
:default: 3600 |
||||
|
||||
The Cache-Control max-age response header value for static files served |
||||
by the zuul-web. Set to 0 during development to disable Cache-Control. |
||||
|
||||
Operation |
||||
~~~~~~~~~ |
||||
|
||||
To start the web server, run ``zuul-web``. To stop it, kill the |
||||
PID which was saved in the pidfile specified in the configuration. |
||||
|
||||
Finger Gateway |
||||
-------------- |
||||
|
||||
The Zuul finger gateway listens on the standard finger port (79) for |
||||
finger requests specifying a build UUID for which it should stream log |
||||
results. The gateway will determine which executor is currently running that |
||||
build and query that executor for the log stream. |
||||
|
||||
This is intended to be used with the standard finger command line client. |
||||
For example:: |
||||
|
||||
finger UUID@zuul.example.com |
||||
|
||||
The above would stream the logs for the build identified by `UUID`. |
||||
|
||||
Finger gateway servers need to be able to connect to the Gearman |
||||
server (usually the scheduler host), as well as the console streaming |
||||
port on the executors (usually 7900). |
||||
|
||||
Configuration |
||||
~~~~~~~~~~~~~ |
||||
|
||||
In addition to the common configuration sections, the following |
||||
sections of ``zuul.conf`` are used by the finger gateway: |
||||
|
||||
.. attr:: fingergw |
||||
|
||||
.. attr:: command_socket |
||||
:default: /var/lib/zuul/fingergw.socket |
||||
|
||||
Path to command socket file for the executor process. |
||||
|
||||
.. attr:: listen_address |
||||
:default: all addresses |
||||
|
||||
IP address or domain name on which to listen. |
||||
|
||||
.. attr:: log_config |
||||
|
||||
Path to log config file for the finger gateway process. |
||||
|
||||
.. attr:: pidfile |
||||
:default: /var/run/zuul-fingergw/zuul-fingergw.pid |
||||
|
||||
Path to PID lock file for the finger gateway process. |
||||
|
||||
.. attr:: port |
||||
:default: 79 |
||||
|
||||
Port to use for the finger gateway. Note that since command line |
||||
finger clients cannot usually specify the port, leaving this set to |
||||
the default value is highly recommended. |
||||
|
||||
.. attr:: user |
||||
:default: zuul |
||||
|
||||
User ID for the zuul-fingergw process. In normal operation as a |
||||
daemon, the finger gateway should be started as the ``root`` user, but |
||||
it will drop privileges to this user during startup. |
||||
|
||||
Operation |
||||
~~~~~~~~~ |
||||
|
||||
To start the finger gateway, run ``zuul-fingergw``. To stop it, kill the |
||||
PID which was saved in the pidfile specified in the configuration. |
||||
@ -0,0 +1,71 @@
|
||||
:title: Connection Configuration |
||||
|
||||
.. _connection-config: |
||||
|
||||
Connection Configuration |
||||
======================== |
||||
|
||||
Most of Zuul's configuration is contained in the git repositories upon |
||||
which Zuul operates, however, some configuration outside of git |
||||
repositories is still required to bootstrap the system. This includes |
||||
information on connections between Zuul and other systems, as well as |
||||
identifying the projects Zuul uses. |
||||
|
||||
.. _connections: |
||||
|
||||
Connections |
||||
----------- |
||||
|
||||
In order to interact with external systems, Zuul must have a |
||||
*connection* to that system configured. Zuul includes a number of |
||||
drivers, each of which implements the functionality necessary to |
||||
connect to a system. Each connection in Zuul is associated with a |
||||
driver. |
||||
|
||||
To configure a connection in Zuul, select a unique name for the |
||||
connection and add a section to ``zuul.conf`` with the form |
||||
``[connection NAME]``. For example, a connection to a gerrit server |
||||
may appear as: |
||||
|
||||
.. code-block:: ini |
||||
|
||||
[connection mygerritserver] |
||||
driver=gerrit |
||||
server=review.example.com |
||||
|
||||
Zuul needs to use a single connection to look up information about |
||||
changes hosted by a given system. When it looks up changes, it will |
||||
do so using the first connection it finds that matches the server name |
||||
it's looking for. It's generally best to use only a single connection |
||||
for a given server, however, if you need more than one (for example, |
||||
to satisfy unique reporting requirements) be sure to list the primary |
||||
connection first as that is what Zuul will use to look up all changes |
||||
for that server. |
||||
|
||||
.. _drivers: |
||||
|
||||
Drivers |
||||
------- |
||||
|
||||
Drivers may support any of the following functions: |
||||
|
||||
* Sources -- hosts git repositories for projects. Zuul can clone git |
||||
repos for projects and fetch refs. |
||||
* Triggers -- emits events to which Zuul may respond. Triggers are |
||||
configured in pipelines to cause changes or other refs to be |
||||
enqueued. |
||||
* Reporters -- outputs information when a pipeline is finished |
||||
processing an item. |
||||
|
||||
Zuul includes the following drivers: |
||||
|
||||
.. toctree:: |
||||
:maxdepth: 2 |
||||
|
||||
drivers/gerrit |
||||
drivers/github |
||||
drivers/git |
||||
drivers/smtp |
||||
drivers/sql |
||||
drivers/timer |
||||
drivers/zuul |
||||
@ -0,0 +1,299 @@
|
||||
:title: Gerrit Driver |
||||
|
||||
Gerrit |
||||
====== |
||||
|
||||
`Gerrit`_ is a code review system. The Gerrit driver supports |
||||
sources, triggers, and reporters. |
||||
|
||||
.. _Gerrit: https://www.gerritcodereview.com/ |
||||
|
||||
Zuul will need access to a Gerrit user. |
||||
|
||||
Create an SSH keypair for Zuul to use if there isn't one already, and |
||||
create a Gerrit user with that key:: |
||||
|
||||
cat ~/id_rsa.pub | ssh -p29418 review.example.com gerrit create-account --ssh-key - --full-name Zuul zuul |
||||
|
||||
Give that user whatever permissions will be needed on the projects you |
||||
want Zuul to report on. For instance, you may want to grant |
||||
``Verified +/-1`` and ``Submit`` to the user. Additional categories |
||||
or values may be added to Gerrit. Zuul is very flexible and can take |
||||
advantage of those. |
||||
|
||||
Connection Configuration |
||||
------------------------ |
||||
|
||||
The supported options in ``zuul.conf`` connections are: |
||||
|
||||
.. attr:: <gerrit connection> |
||||
|
||||
.. attr:: driver |
||||
:required: |
||||
|
||||
.. value:: gerrit |
||||
|
||||
The connection must set ``driver=gerrit`` for Gerrit connections. |
||||
|
||||
.. attr:: server |
||||
|
||||
Fully qualified domain name of Gerrit server. |
||||
|
||||
.. attr:: canonical_hostname |
||||
|
||||
The canonical hostname associated with the git repos on the |
||||
Gerrit server. Defaults to the value of |
||||
:attr:`<gerrit connection>.server`. This is used to identify |
||||
projects from this connection by name and in preparing repos on |
||||
the filesystem for use by jobs. Note that Zuul will still only |
||||
communicate with the Gerrit server identified by ``server``; |
||||
this option is useful if users customarily use a different |
||||
hostname to clone or pull git repos so that when Zuul places |
||||
them in the job's working directory, they appear under this |
||||
directory name. |
||||
|
||||
.. attr:: port |
||||
:default: 29418 |
||||
|
||||
Gerrit server port. |
||||
|
||||
.. attr:: baseurl |
||||
|
||||
Path to Gerrit web interface. |
||||
|
||||
.. attr:: gitweb_url_template |
||||
:default: {baseurl}/gitweb?p={project.name}.git;a=commitdiff;h={sha} |
||||
|
||||
Url template for links to specific git shas. By default this will |
||||
point at Gerrit's built in gitweb but you can customize this value |
||||
to point elsewhere (like cgit or github). |
||||
|
||||
The three values available for string interpolation are baseurl |
||||
which points back to Gerrit, project and all of its safe attributes, |
||||
and sha which is the git sha1. |
||||
|
||||
.. attr:: user |
||||
:default: zuul |
||||
|
||||
User name to use when logging into Gerrit via ssh. |
||||
|
||||
.. attr:: sshkey |
||||
:default: ~zuul/.ssh/id_rsa |
||||
|
||||
Path to SSH key to use when logging into Gerrit. |
||||
|
||||
.. attr:: keepalive |
||||
:default: 60 |
||||
|
||||
SSH connection keepalive timeout; ``0`` disables. |
||||
|
||||
Trigger Configuration |
||||
--------------------- |
||||
|
||||
Zuul works with standard versions of Gerrit by invoking the ``gerrit |
||||
stream-events`` command over an SSH connection. It also reports back |
||||
to Gerrit using SSH. |
||||
|
||||
If using Gerrit 2.7 or later, make sure the user is a member of a group |
||||
that is granted the ``Stream Events`` permission, otherwise it will not |
||||
be able to invoke the ``gerrit stream-events`` command over SSH. |
||||
|
||||
.. attr:: pipeline.trigger.<gerrit source> |
||||
|
||||
The dictionary passed to the Gerrit pipeline ``trigger`` attribute |
||||
supports the following attributes: |
||||
|
||||
.. attr:: event |
||||
:required: |
||||
|
||||
The event name from gerrit. Examples: ``patchset-created``, |
||||
``comment-added``, ``ref-updated``. This field is treated as a |
||||
regular expression. |
||||
|
||||
.. attr:: branch |
||||
|
||||
The branch associated with the event. Example: ``master``. |
||||
This field is treated as a regular expression, and multiple |
||||
branches may be listed. |
||||
|
||||
.. attr:: ref |
||||
|
||||
On ref-updated events, the branch parameter is not used, instead |
||||
the ref is provided. Currently Gerrit has the somewhat |
||||
idiosyncratic behavior of specifying bare refs for branch names |
||||
(e.g., ``master``), but full ref names for other kinds of refs |
||||
(e.g., ``refs/tags/foo``). Zuul matches this value exactly |
||||
against what Gerrit provides. This field is treated as a |
||||
regular expression, and multiple refs may be listed. |
||||
|
||||
.. attr:: ignore-deletes |
||||
:default: true |
||||
|
||||
When a branch is deleted, a ref-updated event is emitted with a |
||||
newrev of all zeros specified. The ``ignore-deletes`` field is a |
||||
boolean value that describes whether or not these newrevs |
||||
trigger ref-updated events. |
||||
|
||||
.. attr:: approval |
||||
|
||||
This is only used for ``comment-added`` events. It only matches |
||||
if the event has a matching approval associated with it. |
||||
Example: ``Code-Review: 2`` matches a ``+2`` vote on the code |
||||
review category. Multiple approvals may be listed. |
||||
|
||||
.. attr:: email |
||||
|
||||
This is used for any event. It takes a regex applied on the |
||||
performer email, i.e. Gerrit account email address. If you want |
||||
to specify several email filters, you must use a YAML list. |
||||
Make sure to use non greedy matchers and to escapes dots! |
||||
Example: ``email: ^.*?@example\.org$``. |
||||
|
||||
.. attr:: username |
||||
|
||||
This is used for any event. It takes a regex applied on the |
||||
performer username, i.e. Gerrit account name. If you want to |
||||
specify several username filters, you must use a YAML list. |
||||
Make sure to use non greedy matchers and to escapes dots. |
||||
Example: ``username: ^zuul$``. |
||||
|
||||
.. attr:: comment |
||||
|
||||
This is only used for ``comment-added`` events. It accepts a |
||||
list of regexes that are searched for in the comment string. If |
||||
any of these regexes matches a portion of the comment string the |
||||
trigger is matched. ``comment: retrigger`` will match when |
||||
comments containing ``retrigger`` somewhere in the comment text |
||||
are added to a change. |
||||
|
||||
.. attr:: require-approval |
||||
|
||||
This may be used for any event. It requires that a certain kind |
||||
of approval be present for the current patchset of the change |
||||
(the approval could be added by the event in question). It |
||||
follows the same syntax as :attr:`pipeline.require.<gerrit |
||||
source>.approval`. For each specified criteria there must exist |
||||
a matching approval. |
||||
|
||||
.. attr:: reject-approval |
||||
|
||||
This takes a list of approvals in the same format as |
||||
:attr:`pipeline.trigger.<gerrit source>.require-approval` but |
||||
will fail to enter the pipeline if there is a matching approval. |
||||
|
||||
Reporter Configuration |
||||
---------------------- |
||||
|
||||
Zuul works with standard versions of Gerrit by invoking the |
||||
``gerrit`` command over an SSH connection. It reports back to |
||||
Gerrit using SSH. |
||||
|
||||
The dictionary passed to the Gerrit reporter is used for ``gerrit |
||||
review`` arguments, with the boolean value of ``true`` simply |
||||
indicating that the argument should be present without following it |
||||
with a value. For example, ``verified: 1`` becomes ``gerrit review |
||||
--verified 1`` and ``submit: true`` becomes ``gerrit review |
||||
--submit``. |
||||
|
||||
A :ref:`connection<connections>` that uses the gerrit driver must be |
||||
supplied to the trigger. |
||||
|
||||
Requirements Configuration |
||||
-------------------------- |
||||
|
||||
As described in :attr:`pipeline.require` and :attr:`pipeline.reject`, |
||||
pipelines may specify that items meet certain conditions in order to |
||||
be enqueued into the pipeline. These conditions vary according to the |
||||
source of the project in question. To supply requirements for changes |
||||
from a Gerrit source named ``my-gerrit``, create a configuration such |
||||
as the following: |
||||
|
||||
.. code-block:: yaml |
||||
|
||||
pipeline: |
||||
require: |
||||
my-gerrit: |
||||
approval: |
||||
- Code-Review: 2 |
||||
|
||||
This indicates that changes originating from the Gerrit connection |
||||
named ``my-gerrit`` must have a ``Code-Review`` vote of ``+2`` in |
||||
order to be enqueued into the pipeline. |
||||
|
||||
.. attr:: pipeline.require.<gerrit source> |
||||
|
||||
The dictionary passed to the Gerrit pipeline `require` attribute |
||||
supports the following attributes: |
||||
|
||||
.. attr:: approval |
||||
|
||||
This requires that a certain kind of approval be present for the |
||||
current patchset of the change (the approval could be added by |
||||
the event in question). It takes several sub-parameters, all of |
||||
which are optional and are combined together so that there must |
||||
be an approval matching all specified requirements. |
||||
|
||||
.. attr:: username |
||||
|
||||
If present, an approval from this username is required. It is |
||||
treated as a regular expression. |
||||
|
||||
.. attr:: email |
||||
|
||||
If present, an approval with this email address is required. It is |
||||
treated as a regular expression. |
||||
|
||||
.. attr:: older-than |
||||
|
||||
If present, the approval must be older than this amount of time |
||||
to match. Provide a time interval as a number with a suffix of |
||||
"w" (weeks), "d" (days), "h" (hours), "m" (minutes), "s" |
||||
(seconds). Example ``48h`` or ``2d``. |
||||
|
||||
.. attr:: newer-than |
||||
|
||||
If present, the approval must be newer than this amount |
||||
of time to match. Same format as "older-than". |
||||
|
||||
Any other field is interpreted as a review category and value |
||||
pair. For example ``Verified: 1`` would require that the |
||||
approval be for a +1 vote in the "Verified" column. The value |
||||
may either be a single value or a list: ``Verified: [1, 2]`` |
||||
would match either a +1 or +2 vote. |
||||
|
||||
.. attr:: open |
||||
|
||||
A boolean value (``true`` or ``false``) that indicates whether |
||||
the change must be open or closed in order to be enqueued. |
||||
|
||||
.. attr:: current-patchset |
||||
|
||||
A boolean value (``true`` or ``false``) that indicates whether the |
||||
change must be the current patchset in order to be enqueued. |
||||
|
||||
.. attr:: status |
||||
|
||||
A string value that corresponds with the status of the change |
||||
reported by the trigger. |
||||
|
||||
.. attr:: pipeline.reject.<gerrit source> |
||||
|
||||
The `reject` attribute is the mirror of the `require` attribute. It |
||||
also accepts a dictionary under the connection name. This |
||||
dictionary supports the following attributes: |
||||
|
||||
.. attr:: approval |
||||
|
||||
This takes a list of approvals. If an approval matches the |
||||
provided criteria the change can not be entered into the |
||||
pipeline. It follows the same syntax as |
||||
:attr:`pipeline.require.<gerrit source>.approval`. |
||||
|
||||
Example to reject a change with any negative vote: |
||||
|
||||
.. code-block:: yaml |
||||
|
||||
reject: |
||||
my-gerrit: |
||||
approval: |
||||
- Code-Review: [-1, -2] |
||||
@ -0,0 +1,59 @@
|
||||
:title: Git Driver |
||||
|
||||
Git |
||||
=== |
||||
|
||||
This driver can be used to load Zuul configuration from public Git repositories, |
||||
for instance from ``openstack-infra/zuul-jobs`` that is suitable for use by |
||||
any Zuul system. It can also be used to trigger jobs from ``ref-updated`` events |
||||
in a pipeline. |
||||
|
||||
Connection Configuration |
||||
------------------------ |
||||
|
||||
The supported options in ``zuul.conf`` connections are: |
||||
|
||||
.. attr:: <git connection> |
||||
|
||||
.. attr:: driver |
||||
:required: |
||||
|
||||
.. value:: git |
||||
|
||||
The connection must set ``driver=git`` for Git connections. |
||||
|
||||
.. attr:: baseurl |
||||
|
||||
Path to the base Git URL. Git repos name will be appended to it. |
||||
|
||||
.. attr:: poll_delay |
||||
:default: 7200 |
||||
|
||||
The delay in seconds of the Git repositories polling loop. |
||||
|
||||
Trigger Configuration |
||||
--------------------- |
||||
|
||||
.. attr:: pipeline.trigger.<git source> |
||||
|
||||
The dictionary passed to the Git pipeline ``trigger | ||||