- Adds the ability for JJB to work with views
- Views can be created, updated, and deleted.
- New modules for List view and Build Pipeline view are added
- New tests for testing the deletion of views
Example View configuration:
- view:
name: MyView
view-type: list
Change-Id: Idb29a4407bcc14593e10a4d951036cb04e8e6c27
Co-Authored-By: Brandon Leonard <brandon.leonard@rackspace.com>
Co-Authored-By: Joao Vale <jpvale@gmail.com>
Co-Authored-By: Lucas Dutra Nunes <ldnunes@ossystems.com.br>
Signed-off-by: Thanh Ha <thanh.ha@linuxfoundation.org>
Output the variable inputs used that trigger an error when expanding
template names to the error logger channel in a sensible format.
Ensures that when indented variable inputs for templates result in
exceptions when expanding a template name, that the project, template
name and variables that failed to be iterated over are outputted in a
log error message along with the original set of inputs from the
project definition to make it easier for end users to find where the
error has been made in a JJB definition.
Add code to allow dumping of variables stored in OrderedDict
transparently to match the input format used in JJB definitions and
hide the implementation detail of using OrderedDict to be within the
localyaml library.
Change-Id: I660bb0ca3b109e1a861948d6a867f185047b90ae
Separate XML generation from Yaml parsing/interpreting. The goal here
is to allow different sources to provide data for XML generation,
including external API users writing job definitions in pure Python or
JJB developers who would like to work on alternative Yaml parsing code
since the current YamlParser has very likely reached the limits of
what can be reasonably done with one giant expandYaml procedure.
Change-Id: I9da848acac7e944c0e07286b7399b2e1956a58a5
Create the ModuleRegistry anywhere other than inside the YamlParser
class. This will make it slightly easier to factor a XmlGenerator out
of YamlParser, but I also want to work toward eliminating the circular
references between YamlParser and ModuleRegistry which have been
making it difficult to understand overall program flow.
This commit also replaces all YamlParser instances being passed to
Jenkins job config generating functions with a ModuleRegistry. Mostly
it seems like the parser was only needed to call the ModuleRegistry's
'dispatch' method which to be honest I don't fully understand. This is
where the circular references mentioned in previously come in...it
seems like the "dispatch" function needs access to the (mostly) raw
data contained by the parser, so it took that as a parameter.
The need for the YamlParser's job data can be satisfied by assigning
it to a property on the ModuleRegistry object before Yaml expansion or
XML generation begins; by doing this, we allow the ModuleRegistry to
avoid referencing the parser.
Change-Id: I4b571299b81e708540392ad963163fe092acf1d9
This is the first step in removing jenkins_modules.parser.YamlParser
references from jenkins_jobs.builder.Builder entirely, necessary
because load_files is actually a YamlParser behavior, not a Builder
behavior.
Change-Id: I1cad99b4cdb44af25ba398837f7f328cfcbd5bbb
Remove reference to ConfigParser object in ModuleRegistry. Instead:
* make use of JJBConfig.get_module_config to grab settings for Hipchat
Notifier Plugin
* make use of JJBConfig.yamlparser['allow_empty_variables'] rather
than repeating ConfigParser logic moved out of the YamlParser into
JJBConfig in an earlier commit.
Change-Id: Icb7ef514826005545e48af993335ce120f973b0d
This commit sees JJBConfig start to take the form it ought to have,
namely using attributes to represent different logical sections of
configuration that target specific subsystems of JJB.
It also moves ConfigParser data retrieval from
jenkins_jobs.modules.helpers.get_value_from_yaml_or_config_file() to
jenkins_jobs.config.JJBConfig.get_module_config()
TODO: Add JJBConfig tests to validate the behavior of JJBConfig in
specific circumstances.
Change-Id: I053d165559f5325a2f40b239117a86e6d0f3ef37
It is useful to allow templates that can have different settings for
slightly different jobs while still following the same naming scheme.
Additionally this allows for shorter and more descriptive names to be
used without the confusion of the variable placeholders, and for the
resulting job names from the templates to be altered without needing to
update all references.
Change-Id: Idc3517b44873210a33f988ebff449ea2ed567054
In complex configurations it may be useful to have a template
print out its name so that a given job can be easily traced to
its definition.
Change-Id: I1cfed9c27a58b45ba48aeed04839bfc8f54a831e
Where n = number of variables in scope for a particular job template instance.
and m = number of job template instance.
Let's imagine for a large set of jobs with n = 100 and m = 50
This debug message makes it difficult to scan through JJB output looking for
signficant debug messages and does not provide a clear value.
It is trivially easy to know which variables are and which are not included in a
job-template's name by simply reading it.
Change-Id: I745e26ac6062277fc477cb1ca70cf2809f5806e3
Ensure file objects including stdin/stdout objects are wrapped using
codecs to handle unicode translation to the selected encoding for
input/output.
Add tests to simulate different encodings for input/output and
consequently fix the reading of input from stdin. Include test to
trigger failure to encode a unicode valid character using 'ascii'
encoding.
Change-Id: I9a5c4c96d131873db0000377729b8b0a45aa470d
Use io.open() to allow reading and writing of files in 'utf-8' format
irrespective of the terminal encoding selected.
Change-Id: Ie952617a34c0719efc59a7729d698beafaa477b0
waynr fixed a bug but explained in concat_defaults002
This bug happens when some values are specified in an other defaults
namespace then global.
This causes JJB to fail that its unable to find the required keys
becasue these were not merged correctly
Change-Id: Id0df24ba7cf8281389c2ed7af7ee716047d0e4a5
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