| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this patch is simply to move some classes out of
jenkins_jobs.builder into more appropriately-named modules. This started with
simply moving YamlParser into jenkins_jobs.parser but led to other moves in
order to avoid cyclic imports since YamlParser uses other classes previously
defined in jenkins_jobs.builder.
That said, this patch doesn't intend to address all of the clutter in
jenkins_jobs.builder, mostly just what is necessary to get started working on
YamlParser independent of other classes in that module.
Change-Id: Ie88bf683e495033eb0b670fe29c256a70282735f
|
| |
|
|
| |
Change-Id: I4f62fad4d2c0e361eddaed6d4db2faa655bd4b11
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
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
|
