Additionally update the plugin to use convert_mapping_to_xml and add
min/max tests.
Change-Id: I8f0a9054c12ea984a286aea1012513baac07479f
Co-Authored-By: Thanh Ha <thanh.ha@linuxfoundation.org>
Signed-off-by: Thanh Ha <thanh.ha@linuxfoundation.org>
Add project folder module. Jenkins folder could be made with project-type: folder
This requires Cloudbees folder plugin and python-jenkins folder update
(see: https://review.openstack.org/#/c/180185/)
Change-Id: I7e1c28c26a69ae6ca736cec88fcb957a716d8fad
Allows specifying a folder attribute for each job generated, which in
turn is used when creating or uploading to place the job under the
requested folder.
The job name is expanded after defaults are applied, to support the
attribute being defined within a set of defaults applied to a number of
jobs.
This in turn allows for multiple jobs with the same basename to exist,
provided they are targeted at different folders.
Does not support creating the folders if they do not exist.
Change-Id: I8c2157c4c81087cc972a048d1b88d5f08ac65361
When specifying a view type that isn't supported by any modules (such as
"list-view" instead of "list"), this ensures that the user is guided
towards something correct.
This changes the error message in this case from:
AttributeError: 'NoneType' object has no attribute 'name'
to:
jenkins_jobs.errors.JenkinsJobsException: Unrecognized view type: list-view (supported types are: list, pipeline)
Change-Id: I0ee800db1c9c8aeecffcf11f1e86c03ba0590da8
This uses the default "All" view columns as the columns for any views
without a columns attribute sets. This means that view definitions
which don't define any columns will still end up producing a useful
view.
(Note that the "All" columns are not fetched from the Jenkins instance;
the columns that are the default in a fresh Jenkins install are
hard-coded.)
Change-Id: I0a21e024be383088c6238c3fc7beb708af8c2c46
Since the 30.01.2017 the SVN plugin support additional-credentials, but the jenkins-job-builder can't generate this part:
<additionalCredentials>
<hudson.scm.SubversionSCM_-AdditionalCredentials>
<realm>...</realm>
<credentialsId>...</credentialsId>
</hudson.scm.SubversionSCM_-AdditionalCredentials>
<hudson.scm.SubversionSCM_-AdditionalCredentials>
<realm>...</realm>
<credentialsId>...</credentialsId>
</hudson.scm.SubversionSCM_-AdditionalCredentials>
</additionalCredentials>
Now you have optional 'additional-credentials' parameters.
Change-Id: I801cada4bd630242a216a1facc4abfc8d5378bcf
Task:4884
Story:2001152
This continues to support the current string form for job configuration,
as well as adding a form that supports a mapping. This mapping has two
keys: "command", containing the command to be executed (i.e. the current
string parameter); and "unstable-return", containing the exit code that
configures the exit code that should cause a build to be marked
unstable.
Change-Id: I43ecc883236bbf8fc6de7ed8992e6d90da7d48ac
Migrate from a global config __future__ to control behaviour to plugin
specific options to decide on whether to take the param order from yaml
when using the trigger-parameterized-builds plugin or when plugins are
making use of it as well.
Adjust the config retrieval to support a default value to simplify
logic around ensuring the behaviour matches 'true' by default.
Remove some redundant logic in helper module handling a default value
lookup and add some additional conf files to continue having some tests
using the old behaviour.
Remove old conf files setting the __futures__.param_order_from_yaml to
true as this is now the default under the correct plugin setting.
Change-Id: Ibd5f549b6d626bacaaa4221015a70aaf03626b00
Getting plugin info requires Administrator permissions. It seems the
test command allows providing the plugin_info details via a yaml
configuration file. This patch allows the same command to be passed to
the update command to allow us to configure the plugin versions manually
and not require administrator permissions.
Additionally this patch adds a new command called get-plugins-info
which can create the plugins_info.yaml file to pass to the
plugin_info_path.
See:
http://lists.openstack.org/pipermail/openstack-infra/2016-June/004388.html
Change-Id: I5a34979407d863a84f34afbf8f565081ec52190a
Signed-off-by: Thanh Ha <thanh.ha@linuxfoundation.org>
Introduce the registry.MacroRegistry class to handle:
* registration of macro types via setuptools' entrypoints
* registration of individual macros for lookup by component list type
* expansion of macros references during YAML "parsing"
As a consequence there is a reduction in performance due to moving the
expansion of macros from inline with XML generation, to requiring
multiple passes over macro component lists.
This decrease in efficiency results in approx ~30-50% increase in unit
test time. Since this will allow for jobs to be expanded from
templates/macros in parallel with future changes, it is a reasonable
short term trade-off as the most computationally expensive task is
updating the definitions on the remote master
Change-Id: I292c6b1f8472370282205426cd8ceb847eb969bd