Interesting. No denying what you propose would not be useful. But maybe at
least for Git you could consider using a post receive hook to lower the
load on your server and not have this kind of issue you're currently having.
My 2 cents.
Le 5 oct. 2013 17:10, "Sascha Vogt" a écrit :
> Hi,
>
> Yes,
Hi,
Yes, I know that, but if you notify a new commit a new "poll task" gets
put in the polling queue. Where it is queued behind a plethora of CVS
polling tasks (which on our system sometimes takes up to 10 minutes
until all the CVS tasks are done and THEN the Git job can finally be
executed).
Re Git, you only need SCM polling ticked - you don't need to actually have
a value in the polling field.
Not sure if that helps but thought I'd mention it.
Richard
On Thursday, September 26, 2013, Sascha Vogt wrote:
> Hi all,
>
> We are currently in the unfortunate situation that we have multip
Hi,
I created https://issues.jenkins-ci.org/browse/JENKINS-19838 and a first
(simple) draft in https://github.com/jenkinsci/jenkins/pull/963
For the moment (due to me lacking time and the proposed solution
perfectly fixing our problem) it only has a checkbox to be enabled, and
if so a queue per S
Hi,
Solution to problem you describe should probably be a per repository
limitation, not for SCM type alone.
Symptoms mentioned in this case are per server, but the proposed solution
focuses on SCM type.
I would see following use cases:
1) multiple servers of the same SCM type where different
Hi all,
We are currently in the unfortunate situation that we have multiple SCM
types (CVS, SVN, Git) and use polling for them. Now, our CVS server is
quite slow and to restrict the load, we have to put a limit on the
concurrent pollings. While the other SCMs are much faster (and with Git
we even
