The existing openapi spec document (used to generate the swagger
ui page in the web app as well as the rst documentation) is
both incomplete and wrong due to bitrot.
This change adds a script which automatically generates much of
the api documentation from the code. The output is still incomplete,
but it does include at least the same endpoints currently documented,
and of those, all of the inputs and outputs.
Due to its automatic generation, all of the endpoints and their
inputs are now documented. Only some outputs are missing (as well
as explanatory text, which was pretty thin before).
It does the following:
* Inspects the cherrypy router object to determine the endpoints to
include, and identifies their HTTP methods and the python functions
that implement them.
* It inspects the function python docstring to get summary documentation
for the endpoint.
* It inspects the function arguments and compares them to the
router path to determine if each is a path or query parameter,
as well as whether each is required.
* It merges type and descriptive information from the python docstring
about each parameter.
* For output, a schema system similar to voluptuous is used to describe
the output names and types, as well as optional descriptive information.
One of two function decorators are used to describe the output.
It removes the documentation for the status page output format. This API
is specially optimized for the Zuul status page, is very complex, and we
should therefore not encourage end-users to develop against it. The
endpoint itself is documented as such, but the response value is
undocumented.
Future work:
More descriptive text and output formats can be documented.
Change-Id: Ib1a2aad728c4a7900841a8e3b617c146f2224953
At the moment API call for fetching SSH public key is not documented
anywhere. It's a bit confusing when a user tries to check through
available calls. This call documented only in ``job-content.rst``.
Change-Id: I69a8d8994b1b4e49ac2c5b07690ebb9ff2a62e38
This updates the OpenAPI docs to include the semaphores endpoint,
and adds a Semaphores tab to the web UI to show information about
semaphores within a tenant.
Change-Id: If78b27131ac76aff93c47a986fce6eae3e068668
This puts the NodesProvisionedEvents into ZooKeeper. With this, all
result events are now in ZooKeeper.
To make the NodesProvisionedEvent serializable, we cannot store the
whole NodeRequest object in the event anymore. Instead we are using the
request.id, job name and the buildset UUID to look up the corresponding
NodeRequest object from the buildset when the NodesProvisionedEvent is
handled.
As a result of this we have to find a way to return the NodeSet even in
case the NodeRequest or the buildset cannot be found anymore (e.g. due
to a gate reset). In this case we look up the NodeRequest directly from
ZooKeeper and provide a faked NodeSet which allows us to retrieve the
node information from Zookeeper (via the update mechanism of the
NodeRequest in the Nodepool client).
Finally, we can get rid of the local result event queue in the scheduler
as now all result events are in ZooKeeper. Together with that the
`zuul.scheduler.eventqueues.result` gauge was also removed.
Change-Id: Ib5e0f13d25a21ebad908d38f0201e92b704a1c85
Zuul currently has a zuul/gated badge that can be linked e.g. in a
readme of a project. This is sufficient for many use cases. However if
a project has periodic jobs that do extended testing which is not
possible in check/gate this is not sufficient. For use cases like
those we can add support for dynamic badges in zuul itself.
Change-Id: I449fa9f38ca251522789b6075fbc876d21bd0200
This change adds a swagger description of the REST API. The description is
rendered in the sphinx user documentations and in the web interface.
Change-Id: I753524f40a09874dab5952f14ab17025525bbab9
Revert "Fix publish-openstack-javascript-content"
This reverts commit ca199eb9db.
This reverts commit 1082faae95.
This appears to remove the tarball publishing system that we rely on.
Change-Id: Id746fb826dfc01b157c5b772adc1d2991ddcd93a
James E. Blair