Non concurrent chain of jobs

[lude]

Hi,

I would like to know if with a plugin it's possible to create a non-
concurrent chain of jobs. I have the following jobs that should be
executed in that order :
A->B->C->D
where A is triggered by SCM changes. B can be triggered by SCM changes
and by A. When 1 job of this chain is being executed, i don't want
other jobs of this chain to start until the currently executing chain
ends. For instance if C is being executed and a SCM change is detected
by A or B, i don't want A or B to start until the running chain ends.
Is it possible to create this kind of configuration in Jenkins where
some jobs belong to a chain that can not be executed concurrently ?

I tried to use the locks and latches plugin but if it guarantees that
only 1 job of this chain is being executed, i don't have control on
the execution order. For instance if B is running and A is triggered,
the next job to be executed will be A instead of C. It's just like
having a build executor of size 1.

[Geoff Bullen]

The build pipeline plugin has a manual trigger.  So, you can set up a
chain of jobs, but the next won't trigger until you press the button.
Builds will trigger via SCM as normal.

Is that roughly what you need?



On 29/05/2011, at 1:40 PM, lude <[hidden email]> wrote:

> Hi,
>
> I would like to know if with a plugin it's possible to create a non-
> concurrent chain of jobs. I have the following jobs that should be
> executed in that order :
> A->B->C->D
> where A is triggered by SCM changes. B can be triggered by SCM changes
> and by A. When 1 job of this chain is being executed, i don't want
> other jobs of this chain to start until the currently executing chain
> ends. For instance if C is being executed and a SCM change is detected

[lude]

It seems that it does, i'll have a look at it.
Thanks

On May 29, 7:43 pm, Geoff Bullen <[hidden email]> wrote:

> The build pipeline plugin has a manual trigger.  So, you can set up a
> chain of jobs, but the next won't trigger until you press the button.
> Builds will trigger via SCM as normal.
>
> Is that roughly what you need?
>
> On 29/05/2011, at 1:40 PM, lude <[hidden email]> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > I would like to know if with a plugin it's possible to create a non-
> > concurrent chain of jobs. I have the following jobs that should be
> > executed in that order :
> > A->B->C->D
> > where A is triggered by SCM changes. B can be triggered by SCM changes
> > and by A. When 1 job of this chain is being executed, i don't want
> > other jobs of this chain to start until the currently executing chain
> > ends. For instance if C is being executed and a SCM change is detected

[Randall R Schulz]

Hi,

Based on the original problem statement in this thread, I believe I have a similar requirement (see this thread). However, I cannot see how the Build Pipeline plug-in accomplishes the exclusion I need.

Basically, I need a Locks & Latches-style lock that applies to the entire execution of a job chain rather than to individual jobs within the chain.

Is that possible?


Randall Schulz

[lude]

Sorry i had read the answer a little bit too quickly, and yes it does
not solve my need to lock a group of jobs.
It would nice to hold a lock at the beginning of a job chain and
release it in case of error or only at the end of the chain.
So far i haven't found any solution for that (without programming with
a Groovy post build action or even creating a plugin).
The only simplistic solution would be to create a single job with
multiple steps (with all the shortcoming that it implies).

Luc

On Jul 21, 1:26 pm, Randall R Schulz <[hidden email]> wrote:

> Hi,
>
> Based on the original problem statement in this thread, I believe I have a
> similar requirement (see this thread<https://groups.google.com/d/topic/jenkinsci-users/q_i025zoRwQ/discussion>).
> However, I cannot see how the Build Pipeline plug-in accomplishes the
> exclusion I need.
>
> Basically, I need a Locks & Latches-style lock that applies to the entire
> execution of a job chain rather than to individual jobs within the chain.
>
> Is that possible?
>
> Randall Schulz