To allow a tenant to use any labels *except* some pattern, add the
disallowed-labels tenant option. Both this and the allowed-labels
option use re2, and therefore lookahead assertions are not supported.
A complimentary option to allowed-labels is the only way to support
this use case.
Change-Id: Ic722b1d2b0b609ec7de583dab159094159f00630
Currently we only can modify the tenant configuration by triggering a
full reconfiguration. However with many large tenants this can take a
long time to finish. Zuul is stalled during this process. Especially
when the system is at quota this can lead to long job queues that
build up just after the reconfiguration. This adds support for a smart
reconfiguration that only reconfigures tenants that changed their
config. This can speed up the reconfiguration a lot in large
multi-tenant systems.
Change-Id: I6240b2850d8961a63c17d799f9bec96705435f19
This changes adds new tenant settings to limit the connection a tenant can
use to trigger from or report to.
Change-Id: I1793ec9c8a249b3a1ce90868086421c8d349d7aa
The config-repo / project-repo terminology is confusing and we've
generally been using trusted-project and untrusted-project instead.
The term "untrusted-project" is straightforward, but "trusted-project"
is a little misleading, since there are other characteristics which
define it (notably, that the configuration held in it is branchless).
A better term for that might be "config-project".
Since the main config now directly refers to projects rather than
repos, complete the transition by replacing all config-repo
occurances with config-project and likewise project-repo with
untrusted-project.
Change-Id: I2341aa94e3622e2647b0506b78bc84dbcdec1901
Story: 2000953
The layout stores the configuration of a project in the ProjectConfig
class (not the Project class -- that represents the abstract idea
of a project independent of Zuul, the ProjectConfig represents a
particular Zuul configuration operating on that project). Therefore,
in the continuing effort to fully qualify project names, index
ProjectConfig objects by their canonical project name. Use that
name when looking for a ProjectConfig to find the jobs to run for
a given change.
Story: 2000953
Change-Id: I733a66369c969770e57c2fa8b30822bd15e1aca7
We need a way to get the ansible playbooks onto the ansible launch
servers. That's easy for jobs defined in-repo because their repo
will already be on the launch server by definition. But for the
tenant-global config, those playbooks (and roles, etc) need to be
made available as well. Rather than shipping them around on the
gearman bus which is inefficient, let's just say that those will
also be in a repo. Probably the same repo that defines the jobs,
ie in our case, the project-config repo.
In other words -- by making the global config one or more repos
that zuul knows about, the merger component of the launch server
can prepare *that* repo as well as the others involved in any
job, so that the playbooks are available to ansible.
This also has the potential upside of making changes that Depends-On
zuul configuration or ansible playbook changes much more natural
to implement.
We also keep track of the source repo for job definitions so that
we can potentially use that to tell the launch server what repos
should be included for playbooks, though this is not plumbed through
yet.
This adds some features to the test framework to copy a directory
in the fixtures dir into a git repo since we're going to have a
lot more 'git repo content' that should just be in the fixtures dir.
It also removes the merge worker from the tests because it was
racing with the ansible launcher cat handler. The merge worker
can probably be completely removed in a later change.
Change-Id: I8fc5a8f627e3d915d54d15e70b7960655a6332a1
Add a test for multiple tenants with a partially shared config.
We might use something like this in OpenStack to define common
pipelines but then have separate tenant config files for groups
of projects.
Change-Id: I29dc9327e3d72d5f6797eb2c366c36fe5be8ea8e
James E. Blair