The defaults can make use of variables passed by the project and I am
taking advantage of that feature in my templates.
With 70ed2236 / https://review.openstack.org/#/c/85336/ there is a
regression which cause the test to fail although it pass with parent
commit d833015.
Change-Id: I57d023657eec4f6f8f29980100185fcfd7e77b1f
This reverts commit 70ed22362a9c13ea9f3165e5747dcca281ad439c.
I knew I should have tested the patch with my own templates. Doing so I
discovered a nasty regression:
The defaults can make use of variables passed by the project. By moving
applyDEfaults to be called after deep_format is performed on job
templates, any substitutioncontained withing defaults is no longer
correctly replaced by project parameters.
Change-Id: I69ffb3e28093af6db62962786d9275bf3ba4e115
Make sure the example referenced in the documentation for ``Job Groups``
actually makes use of 'job-group'.
Change-Id: Ib78bdb459db23f57093c1fd4a6dd74a5080dc239
Add a few tests for JJB command processing. This is just to get
started I'm hoping more will come.
Change-Id: Iff964af025f6a3d7ba4acd91b1e0242285a11bc3
this option allows terminate job phase on specific status of job
Change-Id: I5984fb2494120afc97140c1ae38635301e8f1376
Signed-off-by: Lukas Bednar <lbednar@redhat.com>
Add support for local tags which are application specific to allow
including of other yaml files or code from scripts. Allows for code to
be maintained and tested as seperate files, as well as reduces
duplication of yaml code that cannot be macro'ed or easily templated by
including it from a common file.
Adds support for the following tags:
'include' - load file as yaml code
'include-raw' - load file as data (for scripts)
'include-raw-escaped' - load file as data with escaping braces '{}'
as default for use with job-templates
Use configuration file options to provide a search path for the files.
- Test behaviour of yaml tags independent of any XML generation
by comparing json result of yaml parsing to verify that certain
tags do/don't recall the yaml.load() method.
- Add examples for the include tags via addition tests for YamlParser
class
Inspired by
http://stackoverflow.com/questions/528281/how-can-i-include-an-yaml-file-inside-another
Change-Id: Ib90a07043112d4739d6529ceddbc9817668bcec0
This axis requires the dynamic axis plugin:
https://wiki.jenkins-ci.org/display/JENKINS/DynamicAxis+Plugin
All the dynamic axis plugin settings are in the core project:
<matrix-project>
<axes>
<ca.silvermaplesolutions.jenkins.plugins.daxis.DynamicAxis>
<name>config</name>
<values>
<string>config_list</string>
</values>
<varName>config_list</varName>
<axisValues>
<string>default</string>
</axisValues>
</ca.silvermaplesolutions.jenkins.plugins.daxis.DynamicAxis>
</axes>
The plugin sets 2 values: axis name and variable name.
The axisValue element is hardcoded to 'default' in the plugin, so we do
the same in Jenkins job builder.
The matrix project supports multiple axes configuration, including dynamic
axis.
Tests added for:
* dynamic axis (by itself)
* multiple axes (dynamic and user-defined axes)
Tested on Jenkins LTS (1.554.2) with both the plugin installed and not
installed. The plugin is properly ignored in the latter case.
Change-Id: I36310bc512fd873fec4bd5f42937689fd178536e
Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org>
Since version 2.11.0 the Gerrit Trigger Plugin can be configured to
generate patchset-created events for changes that were uploaded while
the connection to Gerrit was down.
Change-Id: I59608e4f01355944fed9e44b288fc25a897950c7
Concatenate each job XML created from the parsed yaml when using the
YamlParser class for testing. Ensures that multiple jobs created from a
single yaml file can be tested.
Remove erroneous multiple job from scm_remote_deep_bug test.
Change-Id: I2732a7303fefff1f321a1a5b7eef9144d168e39a
The Checkstyle publisher would not honor value of 0 and instead emit
an empty XML element. This was due to the 'if someval' which would be
false whenever someval is 0. Adjusted tests to match the new (and
correct) behavior.
While at it slightly simplified the repeating logic in checkstyle
publisher.
Change-Id: I7443b93aa116dc049de565ff96ca40526b390409
In "SCM module: Add support for multiple Git remotes."
(change Ifef2da85, commit 8a956bcc) there is
recursive dict creation introduced when git repo
does not have any remote configured explicitely in yaml.
But infinite recursion confuses builder.deep_format,
so when defaults section contains scm git entry without
remotes specified, and is used by both:
- single job section (which creates the recursive dict),
- job template (which makes deep_format called on that dict)
it fails on RuntimeException.
Tried to build xmls localy with for example
'test -o /tmp/jobs' action.
Traceback looks like:
File "/jenkins_jobs/cmd.py", line 168, in main
output=options.output_dir)
File "/jenkins_jobs/builder.py", line 583, in update_job
self.parser.generateXML(names)
File "/jenkins_jobs/builder.py", line 241, in generateXML
self.getXMLForTemplateJob(d, template, jobs_filter)
File "/jenkins_jobs/builder.py", line 260, in getXMLForTemplateJob
expanded = deep_format(template, params)
File "/jenkins_jobs/builder.py", line 99, in deep_format
ret[item.format(**paramdict)] = deep_format(obj[item], paramdict)
File "/jenkins_jobs/builder.py", line 95, in deep_format
ret.append(deep_format(item, paramdict))
File "/jenkins_jobs/builder.py", line 99, in deep_format
ret[item.format(**paramdict)] = deep_format(obj[item], paramdict)
File "/jenkins_jobs/builder.py", line 99, in deep_format
ret[item.format(**paramdict)] = deep_format(obj[item], paramdict)
File "/jenkins_jobs/builder.py", line 95, in deep_format
ret.append(deep_format(item, paramdict))
File "/jenkins_jobs/builder.py", line 80, in deep_format
if isinstance(obj, str):
RuntimeError: maximum recursion depth exceeded while calling a Python object
Obj passed to deep_format may look like:
{'origin': {'basedir': 'our-repo',
'branches': ['origin/master'],
'remotes': [<Recursion on dict with id=26090448>],
'url': 'https://our-gerrit.com/our-repo'}}
This patch changes the code to use copy of the git repo dict,
as data for in-place creation of remotes/origin entry,
and as it does not contain 'remotes' key yet, it does not create loop.
Change-Id: Iacd15839c5741cb171253fe45bdd122d7927aa39
instead of using inline examples in docstrings. With literalinclude, we
know the examples are tested.
Change-Id: I95fbb4726bd6731d9687d09a3d6e7d4e5a445131