This renames the internal sphinx domain from zuul to zuuldoc. This
is a temporary measure to avoid colliding with the domain defined
in zuul-sphinx (because of the initial data required, it's not
easy for us to simply add new directives/roles without at least
porting *some* of the framework into zuul-sphinx).
I expect to do that when this has stabilized.
Change-Id: I26be542a6d4f6266f7843ada5939172656b8b847
Depends-On: I8a1534f7c2614ee11411cf228de38931257fc970
The rtfd hook job just does an empty POST to a URI. There's no need to
allocate a node for that, we can just make REST calls from the executor.
Also, there is enough going on here that it needs to be documented. Add
a documentation section to the developer docs about what we're doing
with our ansible plugins. In support of that, add a simple sphinx domain
for ansible to allow us to easily link to upstream ansible documentation for
modules.
Change-Id: I9b0be1018388db7361aec10f30a70437de555615
When we use zuul:value to xref, the default title text for the link
is the full target name (eg "pipeline.trigger.github.event.pull_request")
which is a bit verbose. Normally, we would just want the final element
as the title for a value (so a sentence might read "When a <pull_request>
event is received...").
Change-Id: I42cd678d9bb97058d5fbe255791cbc476d5057bb
We have run into a case where we need to store a secret longer
than 3760 bits. We may eventually support a hybrid encryption
scheme, but for now, let's also support the alt.zuul.secrets protocol
where we split the secret into 3760 bit chunks and recombine it.
The encrypt_secret utility is updated to output a copy-pastable
YAML data structure to simplify dealing with long secrets.
Change-Id: Ied372572e5aa29fddfb7043bf07df4cd3e39566c
This is not complete, but it's a start.
While doing this it became clear that the upstream csvfile lookup plugin does
not work in python3. Work around that by putting in a simpler version of
the code into our copy.
Change-Id: Ic84d8265e6fd7e15a0e5d66c781409a087d761d7
The merger process does not use the state_dir, remove the check
that it exists. It was already undocumented, so this now matches
the documentation.
Change-Id: Ie8cbe75ce4dff774b3f5b3bdaaf324fd9ba6698f
When using a branch and pull model on a shared repository there are
usually one or more protected branches which are gated and a dynamic
number of temporary personal/feature branches which are the source for
the pull requests. These temporary branches while ungated can
potentially include broken zuul config and therefore break the global
tenant wide configuration.
In order to deal with this model add support for excluding unprotected
branches. This can be configured on tenant level and overridden per
project.
Change-Id: I8a45fd41539a3c964a84142f04c1644585c0fdcf
We were incorrectly preparing the current state of the repo for
ref updated (eg, post) jobs. This ensures that we run with the
actual supplied ref, even if the remote has moved on since then.
Change-Id: I52f05406246e6e39805fd8365412f3cb77fe3a0a
This adds a directive (and role) for zuul variables, which also
have a complex hierarchy like configuration values.
The type field may be used to cause, for example, 'items' to render
as 'items[]' to remind users that they must provide an index. It
is ignored for the purposes of the cross-reference role, indices,
and link targets.
Change-Id: I674b17d8257c501cfc5c2f29f2aab9804e9ec846
The git shas 40*'0' are used on the wire protocol to indicate that
the receiving end should create or delete the ref regardless of
its current value. Both Gerrit and GitHub pass these through
on their event streams unaltered.
To make this more convenient for ansible users, translate these
values into undefined variables. So that rather than deterimining
that a ref was created by comparing oldrev to
0000000000000000000000000000000000000000 the user can say
"oldrev is not defined".
Change-Id: I1a2a30a0ad53d50325f189a3829f7428db72e1d1
It is helpful to expose the work_root into the inventory. Today, we
would need to use a relative path on log_root or src_root. Having the
absolute path is better to read for debugging.
Change-Id: I86ff459d283eaf348821c2f11c1f8575598f088d
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
When enabling merge in a github gate pipeline merge message formatting
fails with an exception [1]. The reason for this is a missing
initialization of the GithubUser data structure which is using lazy
initialization (presumibly due to api rate limiting). This is fixed by
adding the initialization.
This was uncovered in the tests because the FakeGithubConnection
directly returns a data structure instead of a GithubUser object like
the real GithubConnection. This is fixed by returning a real
GithubUser object linked to a FakeGithub object.
[1] 2017-08-02 07:13:21,323 ERROR zuul.DependentPipelineManager: Exception while reporting:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/zuul/manager/__init__.py", line 786, in _reportItem
ret = self.sendReport(actions, item)
File "/usr/lib/python3.6/site-packages/zuul/manager/__init__.py", line 168, in sendReport
ret = reporter.report(item)
File "/usr/lib/python3.6/site-packages/zuul/driver/github/githubreporter.py", line 73, in report
self.mergePull(item)
File "/usr/lib/python3.6/site-packages/zuul/driver/github/githubreporter.py", line 129, in mergePull
message = self._formatMergeMessage(item.change)
File "/usr/lib/python3.6/site-packages/zuul/driver/github/githubreporter.py", line 168, in _formatMergeMessage
if not account:
File "/usr/lib/python3.6/site-packages/zuul/driver/github/githubconnection.py", line 340, in __len__
return len(self._data)
TypeError: object of type 'NoneType' has no len()
Change-Id: Ieb9694ff0c98c8cc4011cd4e36627e8ed647d078
Currently, when a project pipeline invokes a job which otherwise
doesn't exist, zuul simply runs nothing. As this is not the desired
behavior add a check during configuration time.
This also uncovers some bugs in the tests which are also fixed.
Change-Id: I37da435fdf3281f98ca097d79d504c170c13bf3a
Story: 2000893
Using the pipeline description as the status description seemed like a
good idea at first, however some sites will make use of lengthy
descriptions which can overflow GitHub's 1024 byte limit on the status
description. To keep the description smaller, simplify by using a simple
template of "{pipeline_name} status: {status}". This could still
overflow if a site uses an unusually large name for a pipeline, so do
some effort to prevent such an overflow. In testing, it seems anything
over 140 characters seems to trip the size limit in GitHub, which
doesn't make a lot of sense, but it's what we have to deal with.
Change-Id: I5255f6cf307f54cd1366f6cb325ed66c1bc4bc27
Story: 2001138
Task: 4854
James E. Blair