Use a simple object to ensure matching against any default value is
possible to distinguish been not being set by a user versus use of
a negative default value passed.
This prevents triggering an incorrect notification to the user when
the code is querying for plugin options that could override the
default behaviour and the compatibility code attempts to look up an non
existing section. It would fail to distinguish between no section
present and current value to return matching the default value
suggested.
Change-Id: I5597c2628ccb5a4282a97a4ce5d3bbe41bd9eebb
- 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>
Since both of these classes essentially build on basic functionality
provided by jenkins.Jenkins, merge them into a single class. Name this
class "JenkinsManager" to avoid confusion with jenkins.Jenkins.
Also moves some tests for update timeout configuration into the
tests.cmd.test_config module from tests.cmd.subcommand.test_update
module, replacing those tests with skipped stubs as reminders to
figure out a better way later.
Change-Id: I13c17bc90e29e702e5e02992e93cf3cdc689731d
Make sure that flush cache is correct set first by config file, and
additionally that the CLI overrides any defaults.
In the V2 API work, when moving code around the flush cache option was
accidentally removed from being set by the command line or config
files. This ensures it follows the same behaviour as other similar
options.
Change-Id: I9fb1e234e5ed081ada64855389a87d2f7555469e
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
Ensure that argparser object only makes use of the JJBConfig object
instead of leaking a command line parser into a config object for API
usage.
Take care to use 'None' as default for store_true/store_false options
in order to ensure that the config file defaults are only overridden
when CLI options are explicitly set.
Change-Id: I4066ad750f9893759c2e9bdfde425fafacc7e672
* Create jenkins_jobs.config module with JJBConfig class.
* Move DEFAULT_CONF from jenkins_jobs.cmd into jenkins_jobs.config
* Move configuration initialization into JJBConfig
* Create method, "do_magical_things" to handle arbitration between
config file and arguments as well as setting default values for
config file settings if it doesn't contain the expected keys.
* Move JenkinsJobs.create_parser into its own module,
jenkins_jobs.cli.parser, it can be used to provide default settings
in the JJBConfig class when an argparse namespace object is not
provided; this is primarily necessary because most of the original
configuration initialization code relies on this being a namespace
object (simple descendant of the object class).
At this point JJBConfig isn't much more than an object-oriented
version of the way configuration handling happened previously. Its
current form, however, is more amenable to the ultimate goal of the
2.0 refactorings--namely, being able to pass a single config object
around rather than breaking it up into apparently arbitrary settings
necessary to instantiate the Builder class and its delegate objects.
Change-Id: Ic0147e1dccbe620aaaba039a434e7cea6c670054
This commit intentionally introduces a number of important API
breakages. Specifically, the jenkins_jobs.cmd module has been pared
down to some of its most difficult-to-refactor elements.
* Create jenkins_jobs.cli.entry.JenkinsJobs class to organize command
line parsing and execution.
* Remove references to ConfigParser object in test code, hidden as an
implementation detail of JenkinsJobs command line parsing. This will
be necessary in the next stage of JJB 2.0 code which will be to
create a JJBConfig object that handles logic and presentation of
configuration from various sources--defaults, command line
arguments, configuration file, and maybe environment variables in
the future.
* Remove references to Namespace object produced by argparse module.
Required rewrite of multipath & recursive path tests with a new
MatchesDir testtools Matcher class that validates the expected
output for a run of JJB against a given set of yamldirs with the
specified command line arguments.
* Use stevedore to dynamically load subcommand parsers.
* Move configuration loading/testing to its own test file. Also fix
the global vs home directory JJB config file test.
Change-Id: If62280418ba7319c313033ab387af4284237747e