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
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
Remove the old default hipchat configuration style in favour of
using the new plugin style and provide a mechanism to copy the url
value from the jenkins section automatically as part of a simple
migration.
This will allow removal of querying the jenkins section from existing
module code and allow for better isolation.
Change-Id: I6889777904ebabc01c044abcd31c9d8a20c255c4
This improves UX by using a alphanum sorting which
is more natural to humans: [a1, a2, a10] instead of
[a1, a10, a2].
Change-Id: Ice9c3de282f08e85c8f8a34a27d1b6c0502ca9cb
Signed-off-by: Sorin Sbarnea <ssbarnea@redhat.com>
This template included using !include-jinja2:
"""
{{ my_var }}
"""
is rendered the same as an existing template that looks like this:
"""
{my_var}
"""
This also allows the use of Jinja2's richer syntax:
"""
{% for test_environment in configuration.get("envs", ["py35"]) %}
tox -e {{ test_environment }}
{% endfor %}
"""
Story: 2001135
Change-Id: Ia3ee21822d6e9237f5ea46796bc8810ecac61e2c