opendev/system-config
Code Issues Proposed changes

Remove Jenkins related documentation fragments

Browse Source 
Change-Id: I4cc5b6e11634f3705ceedc0f1f12309f43e1d8e6
This commit is contained in:
Piotr Parczewski 2021-04-18 21:42:04 +02:00
parent 6e7c07411b
commit ac8fa36a1e
1 changed files with 4 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
doc/source/third_party.rst
View File

@ -8,7 +8,7 @@ Overview
Gerrit has an event stream which can be subscribed to. Using this event stream,
it is possible to test commits against testing systems beyond those supplied by
OpenStack's Jenkins setup. It is also possible for these systems to feed
OpenDev Zuul setup. It is also possible for these systems to feed
information back into Gerrit and they can also leave non-gating votes on Gerrit
review requests.
@ -126,7 +126,7 @@ Posting Result To Gerrit
------------------------
External testing systems can give non-gating votes to Gerrit by means
of a -1/+1 verify vote. OpenStack Jenkins has extra permissions to
of a -1/+1 verify vote. OpenDev Zuul has extra permissions to
give a +2/-2 verify vote which is gating. Comments should also be
provided to explain what kind of test failed. We do also ask that the
comments contain public links to the failure so that the developer can
@ -149,14 +149,6 @@ setup to test on if required. In SmokeStack's case all failures are manually
reviewed before getting pushed to OpenStack, while this may not scale it is
advisable during the initial testing of the setup.
There are several triggers that gerrit will match to alter the
formatting of comments. The raw regular expressions can be seen in
`gerrit.pp <https://opendev.org/opendev/system-config/src/branch/master/modules/openstack_project/manifests/gerrit.pp>`_.
For example, to have your test results formatted in the same manner as
the upstream Jenkins results, use a template for each result matching::
* test-name-no-spaces http://link.to/result : [SUCCESS|FAILURE] some comment about the test
.. _request-account-label:
Creating a Service Account
@ -328,59 +320,13 @@ Here’s a snippet from that file that constructs the ``check`` pipeline taken f
This pipeline is configured to trigger on any Gerrit event that represents a new
patch set created. The matching event will invoke the configured Jenkins job(s)
(discussed next). If all the Jenkins jobs are successful, Zuul will add a comment
patch set created. The matching event will invoke the configured job(s)
(discussed next). If all the jobs are successful, Zuul will add a comment
to Gerrit with a ``verified +1`` vote, and if any one fails, with a ``verified -1``.
In case of merge failure Third Party CI should not comment, but check merger-debug.log
and recheck the patch manually if needed.
Email will be sent to notify the owner about the issue.
The sample includes other possible configurations, or you can configure your own by
following the `Zuul layout documentation <http://docs.openstack.org/infra/zuul/zuul.html#layout-yaml>`_
After a Gerrit event matches a pipeline, Zuul will look at the project identified
in that Gerrit event and invoke the Jenkins jobs specified in the ``projects`` section
(for the matching pipeline) using the `Jenkins Gearman Plugin
<https://wiki.jenkins-ci.org/display/JENKINS/Gearman+Plugin>`_.
For example:
.. code-block:: yaml
projects:
- name: opendev/ci-sandbox
check:
- my-sandbox-check
test:
- my-sandbox-test
In this case, any Gerrit event generated from the ``opendev/ci-sandbox`` project, that matched
the ``check`` pipeline would run the ``my-sandbox-check`` job in Jenkins. If the
Gerrit event also matched the ``test`` pipeline, Zuul would also invoke the ``my-sandbox-test``
Jenkins job.
The following documentation explains how to setup a 3rd party CI system using this approach.
`OpenStack Third-Party CI <http://docs.openstack.org/infra/openstackci/>`_
Managing Jenkins Jobs
---------------------
When code is pushed to Gerrit, a series of jobs are triggered that run a series
of tests against the proposed code. Jenkins
is the server that executes and
manages these jobs. It is a Java application with an extensible architecture
that supports plugins that add functionality to the base server.
Each job in Jenkins is configured separately. Behind the scenes, Jenkins stores
this configuration information in an XML file in its data directory.
You may manually edit a Jenkins job as an administrator in Jenkins. However,
in a testing platform as large as the upstream OpenStack CI system,
doing so manually would be virtually impossible and fraught with errors.
Luckily, there is a helper tool called `Jenkins Job Builder (JJB)
<http://docs.openstack.org/infra/jenkins-job-builder/>`_ that
constructs and manages these XML configuration files after reading a
set of YAML files and job templating rules. These references provide more details:
Testing your CI setup
---------------------