4 Commits

Author SHA1 Message Date
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 7100a7f225e60936f23d24c757c1b14c9b136ec4.

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