Commit Graph

6 Commits

Author SHA1 Message Date
Vsevolod Fedorov f4d64f9f66 Move tests to pytest
Pytest makes each scenario into individual selectable test.
To be able to run each scenario separately is very useful for development.

Change-Id: I4b1c990a1fd839ce327cd7faa27159a9b9632fed
2022-12-20 10:44:43 +03:00
Thanh Ha 4d90c187a9 Auto-generated output from python-black
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>
2019-09-09 19:23:24 +01:00
Wayne Warren dfc0efb79c
Rename "parallelize" decorator to "concurrent"
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
2016-08-18 22:47:48 -04:00
David Caro 333fdc65a1
Add parallelization options
* 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>
2015-12-01 10:05:04 -05:00
James E. Blair f74ce34d36 Revert "Added parallelization options"
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
2015-05-05 18:30:03 +00:00
David Caro 7100a7f225 Added parallelization options
* 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>
2015-04-30 21:33:08 +02:00