ab7c6bc6c1
Move test.sh to the tools directory. Move parameters and notifications to their own modules; even though they are implemented as Jenkins properties, they make more sense as separate entities in the job builder, because that's they way they are specified in the YAML. All three modules that touch the properties xml object know how to create it if it's missing. Change-Id: I4b42ff10a93fd3ed98f632b58e47f3e0e45086d6 Reviewed-on: https://review.openstack.org/12741 Reviewed-by: Clark Boylan <clark.boylan@gmail.com> Approved: James E. Blair <corvus@inaugust.com> Tested-by: Jenkins
68 lines
2.3 KiB
ReStructuredText
68 lines
2.3 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).
|