- update cucumber-testresult plugin to use convert xml
- add plugin="cucumber-testresult-plugin" attribute
- add new parameter 'ignore-bad-steps' support
- update test cases
Change-Id: I8ef353fea030dc0aab0cf9f006fdc84c72834ee7
Switch to import module helpers to keep things tidy.
Change-Id: I366124daf8ea670001ac85ec285955bb3b474fef
Signed-off-by: Kien Ha <kienha9922@gmail.com>
The deprecation warning message in this method was confusing and
seemed to be intended for builder.Jenkins.update_job but it's hard to
tell for sure. Seems likely to be an artifact of an outdated patchset
in the parallelize-the-things work done last year because it's not
clear how it could apply to builder.Builder.update_jobs which has a
significantly different use case than parallel_update_job.
Change-Id: Ifb3c1a40d81b0d43ac8e85151f0a99d1502e21db
Re-add configuration of the logging for CLI, which was accidentally
removed in refactoring.
Remove local instance of logger variable as also defined at the module
level.
Change-Id: Idea548d5a4ed52fd7f9ccb13f9b4e898cd9cc616
If disabled is configured to anything the existing code returns true.
Typically what was done to avoid this was to ensure disabled was
returned in the job as {obj:disabled} to keep the original type. However
if the user uses a JJB 'defaults', defaults always return a string so
{obj:disabled} does not receive a boolean it's expecting causing
disabled's value to always be a string which in code returns as true
always.
Change-Id: Ifd391945fbc7478a10d794e50a61559688c1a23e
Signed-off-by: Thanh Ha <thanh.ha@linuxfoundation.org>
It came to my attention when I was deciding whether or not to use the
jenkins_jobs.parallel.parallelize decorator to parallelize things in
jenkins_jobs.parser that because it is using the Python threading
library nothing is actually parallelized, only concurrentized (at least
for CPython).
I actually think concurrency is fine for the original use case since
that (ie, updating Jenkins jobs) is primarily I/O bound on network
connections to a Jenkins instance. However, the "parallel" name really
is misleading and could actually be harmful for users of this API who
may mistakenly have the impression that it can be used to speed up
CPU-bound tasks.
Also removes seemingly unnecessary usages of this decorator. ie,
jenkins_jobs.builder.Jenkins.changed that is never actually calle
with a list of arguments.
Change-Id: I996f9dea440e2d6b67ea70870d22942d6eef3ec7
Separate XML generation from Yaml parsing/interpreting. The goal here
is to allow different sources to provide data for XML generation,
including external API users writing job definitions in pure Python or
JJB developers who would like to work on alternative Yaml parsing code
since the current YamlParser has very likely reached the limits of
what can be reasonably done with one giant expandYaml procedure.
Change-Id: I9da848acac7e944c0e07286b7399b2e1956a58a5
Create the ModuleRegistry anywhere other than inside the YamlParser
class. This will make it slightly easier to factor a XmlGenerator out
of YamlParser, but I also want to work toward eliminating the circular
references between YamlParser and ModuleRegistry which have been
making it difficult to understand overall program flow.
This commit also replaces all YamlParser instances being passed to
Jenkins job config generating functions with a ModuleRegistry. Mostly
it seems like the parser was only needed to call the ModuleRegistry's
'dispatch' method which to be honest I don't fully understand. This is
where the circular references mentioned in previously come in...it
seems like the "dispatch" function needs access to the (mostly) raw
data contained by the parser, so it took that as a parameter.
The need for the YamlParser's job data can be satisfied by assigning
it to a property on the ModuleRegistry object before Yaml expansion or
XML generation begins; by doing this, we allow the ModuleRegistry to
avoid referencing the parser.
Change-Id: I4b571299b81e708540392ad963163fe092acf1d9
We need post-send script option to configure presendScript in the
generated configure xml.
When setting post-send as below:
postsend-script: $DEFAULT_POSTSEND_SCRIPT
We could see below informaton in the generated configure xml.
<hudson.plugins.emailext.ExtendedEmailPublisher plugin="email-ext@2.42">
<postsendScript>$DEFAULT_POSTSEND_SCRIPT</postsendScript>
</hudson.plugins.emailext.ExtendedEmailPublisher>
Change-Id: Ic215b2f3a9b5e7361a2cc1772226382da341ecd1
Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
Signed-off-by: Jerry Liu <primerlink@gmail.com>