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
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
The info on using list and dict as parameters seemed a little too advanced
to be in the description of 'templates'. This change moves this example into
a newly created 'advanced' configuration section.
Change-Id: I98b80233c45ac721819360743dcae5e82c63ecbf
Change I059f38d0aa8a8947aaac75e0ddb34d392063ece3 added support for
passing parameters to jobs in groups but not for variable substitution
on those parameters. Substitution on job list parameters would
be a new feature. This change removes a misleading parameter subsitution
example.
Partial-bug: #1298568
Change-Id: I18e28bb622f0473f049963ce6dcf6c4efd11dc2c
The same job definition and examples were in both general.rst and
configuration.rst. Moved the contents of general to configuration.
Change-Id: Iefdf1b6ac3b9679a8af4451710442bf58054d790
github.com/openstack-ci was moved to github.com/openstack-infra
homepage references should point to git.o.o/cgit/openstack-infra
This change updates the above references accordingly.
Change-Id: I4d3591f228b10de050a129ae7af99485f50edab5
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
E.g.:
jenkins-jobs test < config/jenkins.yml
This is convenient for demoing or implementing functional tests.
Change-Id: I4e3030e261d3b90f75e4a033ea074d18764d97bf
When you do not specify any description for a job, right now it creates a
new one overwriting whatever you had put there manually. Now when
setting the configuration option 'keep_descriptions' to True, it will
only overwrite the description if you specified one explicitly in the
yaml.
That way you can avoid specifying any description and it will not
overwrite the ones you put there manually through the jenkins ui.
Added a couple of tests for it also, and extended the tests to allow custom
configuration by adding a *.conf file for it
Change-Id: I408f5ee06a6939a8cb8f4f2e6c6e0d060462259c
Signed-off-by: David Caro <dcaroest@redhat.com>
As mentioned at the mail list[0]:
"So I need another way how to pass a *list* as data structure from
the defaults/project down to the job-template definition, similar to
what can be done with "{variable}" for strings."
[0] http://lists.openstack.org/pipermail/openstack-infra/2014-February/000799.html
Closes-Bug: 1281038
Change-Id: I5b04ddb52e537fedd2d05795e91011afd92f2295
The Sphinx documentation now make use of the `program-output` plugin
which would invoke commands to generate inline documentation. Ex:
program-output:: zuul --help
program-output:: zuul enqueue --help
We want the resulting output to correspond to Zuul source code, not the
command which is currently installed on the host running the doc. On my
setup sphinx would die out because it cant find the command 'zuul'.
The new tox environement 'doc' runs sphinx in a virtual env which will
have the proper zuul command.
The generated doc is not written under the /.tox directory but to
/doc/build/html for convenience.
Example usage:
tox -edoc && open doc/build/html/index.html
Change-Id: Ib0170f94bb2c09eb60e555a32e101e2e0959b18e
It was not clear that the project-specific parameters are actually a variables.
Improving the example to make it more clear.
Change-Id: I919562d4df53542ff0d4d60cf0fafc81b69aff1a
They're configured like the other builders but one needed to check the
source to verify this until now.
Change-Id: I97400ad9c7cb0dfb89fe2757c4bedce639e7ea24
Parses jenkins_jobs.ini to look for an ignore_cache flag.
If ignore_cache command line option is sent, it takes priority
over the jenkins_jobs.ini configuration.
Change-Id: I88f1ce1aa0d3e0ad25d592d3ca44a022ec9249c3
Closes-Bug: #1193444
Add documentation on how to generate documentation and run JJB unit tests.
Also added a unit tests for each category of plugins as examples for others
to follow when adding new JJB plugins. I'm hoping this will help contributors
add tests for new plugins going forward.
Change-Id: I2ab90cdb37d0f3b1e947345d4291d2927b04a0c6
There is apparently no way to clear this property using the REST api
once it is set, and the included documentation change warns of that.
Change-Id: I49c5a91664cd37196f3239854bb0adbcf5b3c9f9
The approach is pretty straigh forward, it consists of one new
module handling the project-type "flow". It supports the only field
needed by this kind of project an XML block containing the flow
description in a custom DSL.
Change-Id: I5195391609b3058ae9e24a59024e0cc7a69b16a0
Implements: blueprint jenkins-job-builder-flow
Running Sphinx 1.2b1 running in strict mode (-W), yields three different
errors:
* .. Running:: is an unknown command, uses '.. rubric::' instead
* double stars '**' needs either to be escaped with backslashes or
quoted literrally with double backquotes
* nested lists needs newlines before and after for some reason.
Change-Id: I8680aef7306c619c817c637882715f5a7d08c5d9
Adding job-specific substitutions in a job group's job list
would result in JJB crashing with the following error:
TypeError: unhashable type: 'dict'
This change adds the ability to add job-specific substitutions
in a job group's job list. It implements the same logic used by
a previous change (6ff1d69).
Change-Id: I059f38d0aa8a8947aaac75e0ddb34d392063ece3
* doc/source/configuration.rst: In a literal string within a
template, deep_format will interpret braces as delimiting an
expansion parameter unless doubled up. Document this.
Change-Id: I703f03f89436a09d64b79b147bec6441e1f8cc38
Closes-Bug: #1210293
Jenkins executes the JJB modules in a specific order.
It helps users to understand the order when creating
jenkins jobs.
Change-Id: I134ccf927cb387a0d112a8bedb446fe96196eb84
I implemented this plugin as I use Jenkins Metadata plugin heavily in all my
projects instead of the default Parameters plugin and think that everyone else
would benefit from this addition to JJB as well.
Current implementation handles dates in epoch format only and does not handle
'node' element - so no metatree creation is possible.
Change-Id: I1e67224df9339f1319a371d049585c8343301f2e
Reviewed-on: https://review.openstack.org/33773
Reviewed-by: James E. Blair <corvus@inaugust.com>
Approved: Clark Boylan <clark.boylan@gmail.com>
Reviewed-by: Clark Boylan <clark.boylan@gmail.com>
Tested-by: Jenkins