jenkins-job-builder/doc/source/extending.rst
Arnaud Fabre 38f57ae400 Make reuse of builders/publishers inside other components easier.
Some Jenkins plugins depend on other plugins, and their configuration
section is a mix of both plugins.

For Jenkins Job Builder, that means reusing one component directly from
another one.

Driving the generation of XML markup is the job of Base._dispatch.
Unfortunately, components do not have access to their module object,
and even if their could, _dispatch would still be a non-public method.

Refactor Base._dispatch into ModuleRegistry.dispatch, which can be used
from any place where the parser is available.

Base and ModuleRegistry are extended so that the registry can discover
which entry point must be used for each module, if appropriate.
ModuleRegistry.dispatch signature can be simplified by dropping
component_list_type parameter.

Change-Id: Ie9d090817d0c2d464745b5634a22d3cea6a47ab1
Reviewed-on: https://review.openstack.org/26051
Reviewed-by: James E. Blair <corvus@inaugust.com>
Reviewed-by: Jeremy Stanley <fungi@yuggoth.org>
Approved: Clark Boylan <clark.boylan@gmail.com>
Reviewed-by: Clark Boylan <clark.boylan@gmail.com>
Tested-by: Jenkins
2013-04-24 17:50:32 +00:00

80 lines
2.6 KiB
ReStructuredText

.. _extending:
Extending
=========
Jenkins Job Builder is quite modular. It is easy to add new
attributes to existing components, a new module to support a Jenkins
plugin, or include locally defined methods to deal with an
idiosyncratic build system.
XML Processing
--------------
Most of the work of building XML from the YAML configuration file is
handled by individual functions that implement a single
characteristic. For example, see the
``jenkins_jobs/modules/builders.py`` file for the Python module that
implements the standard Jenkins builders. The ``shell`` function at
the top of the file implements the standard `Execute a shell` build
step. All of the YAML to XML functions in Jenkins Job Builder have
the same signature:
.. _component_interface:
.. py:function:: component(parser, xml_parent, data)
:noindex:
:arg YAMLParser parser: the jenkins jobs YAML parser
:arg Element xml_parent: this attribute's parent XML element
:arg dict data: the YAML data structure for this attribute and below
The function is expected to examine the YAML data structure and create
new XML nodes and attach them to the xml_parent element. This general
pattern is applied throughout the included modules.
.. _module:
Modules
-------
Nearly all of Jenkins Job Builder is implemented in modules. The main
program has no concept of builders, publishers, properties, or any
other aspects of job definition. Each of those building blocks is
defined in a module, and due to the use of setuptools entry points,
most modules are easily extensible with new components.
To add a new module, define a class that inherits from
:py:class:`jenkins_jobs.modules.base.Base`, and add it to the
``jenkins_jobs.modules`` entry point in your setup.py.
.. autoclass:: jenkins_jobs.modules.base.Base
:members:
:undoc-members:
:private-members:
.. _component:
Components
----------
Most of the standard modules supply a number of components, and it's
easy to provide your own components for use by those modules. For
instance, the Builders module provides several builders, such as the
`shell` builder as well as the `trigger_builds` builder. If you
wanted to add a new builder, all you need to do is write a function
that conforms to the :ref:`Component Interface <component_interface>`,
and then add that function to the appropriate entry point (via a
setup.py file).
.. _module_registry:
Module Registry
---------------
All modules and their associated components are registered in the
module registry. It can be accessed either from modules via the registry
field, or via the parser parameter of components.
.. autoclass:: jenkins_jobs.builder.ModuleRegistry
:members: