Pytest makes each scenario into individual selectable test.
To be able to run each scenario separately is very useful for development.
Change-Id: I4b1c990a1fd839ce327cd7faa27159a9b9632fed
Please review the following patch containing the code changes in
the repo. This patch is a transition patch and is the auto-generated
output of the python-black tool.
Change-Id: I2d2de71da8a105fb62b561899ae78441ddab4032
Signed-off-by: Thanh Ha <zxiiro@gmail.com>
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
* Only update_jobs uses the parallel features right now
* --workers N
- If set to 0, it will use parallel execution and
use the number of cores in the machine as thread count
- Any other value enables the parallel extensions and sets the
number of concurrent threads to that value
- Will use 1 by default
Add some tests to make sure the parallel execution helpers work as
expected.
Change-Id: Ib0abd34ea7525f75fff4ff480287a6e589deba90
Signed-off-by: David Caro <dcaroest@redhat.com>
This reverts commit 7100a7f225.
The referenced commit, in addition to what it advertises, also
filters the result of update_jobs to include only changed jobs.
If there are no change jobs, then, if the user specifies
--delete-old, there are no jobs in the list of jobs to keep
which comes from the result of update_jobs. In that case, all
jobs are deleted. Or in other words, the logic in this change
is that all jobs not updated are deleted.
Proposing as a revert because this is currently causing serious
problems for continuously deployed JJB instances, and the very
common --delete-old code path should be properly tested with
this change before it lands again.
Change-Id: I98443f0c085e27ed8dfece6409434015ac24b306
* Only update_jobs uses the parallel features right now
* --workers N
- if set to 0, it will use parallel execution and
use the number of cores in the machine as thread count
- Any other value enables the paralllel extensions and sets the
number of concurrent threads to that value
- Will use 1 by default
Added some tests to make sure the parallel execution helpers work as
expected
Change-Id: Iee8426ff2dc4c5b4ebec4c15bdd21cae5b47eb83
Signed-off-by: David Caro <dcaroest@redhat.com>
Vsevolod Fedorov
Thanh Ha
Wayne Warren
David Caro
James E. Blair