Remove Jenkins related documentation fragments

Change-Id: I4cc5b6e11634f3705ceedc0f1f12309f43e1d8e6

doc/source/third_party.rst

@@ -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)
+patch set created. The matching event will invoke the configured job(s)
-(discussed next). If all the Jenkins jobs are successful, Zuul will add a comment
+(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
 ---------------------