Or just use Gerrit and the Gerrit trigger plugin :-)
On 31 December 2014 14:59:28 GMT+00:00, Mark Waite
wrote:
>If that's the case, you should probably consider the pre-tested commit
>plugin that is part of the Cloudbees commercial offering.
>
>On Wed, Dec 31, 2014 at 7:48 AM, Steve K
>
>wrote:
Am 31.12.2014 um 15:59 schrieb Mark Waite:
> If that's the case, you should probably consider the pre-tested commit
> plugin that is part of the Cloudbees commercial offering.
Or use a branch based development approach and some lines of script code
to let Jenkins do the pull - merge - build - tes
If that's the case, you should probably consider the pre-tested commit
plugin that is part of the Cloudbees commercial offering.
On Wed, Dec 31, 2014 at 7:48 AM, Steve K
wrote:
> Jason, Yes. True. Development wants to ensure no commits are received
> (added to the repo) unless they pass all the
Jason, Yes. True. Development wants to ensure no commits are received
(added to the repo) unless they pass all the tests
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
> -Original Message-
> From: Rob Mandeville
> Sent: Wednesday, December 31, 2014 8:57
>
[reformatted to make sense...]
>> From: Steve K
>> Sent: Tuesday, December 30, 2014 3:21 PM
>>
>> Let's say that, since my most recent build, there have been
>> three (3) new commits.
>> Rather than h
You might also consider writing your own plugin as an extension of the git
plugin.
The git plugin already has the ability to schedule multiple runs of the
same job from a single polling result. It schedules more than one
execution of the same job when it detects more than one matching new branch
It can be (mostly) done, but you are intentionally defeating a Jenkins feature
and you need to take that into account.
When a job is monitoring a Git repository, there are two problems. First off,
by default it polls. If two commits get in within the same poll interval,
you’re getting both.
Am 30.12.2014 um 21:21 schrieb Steve K:
> Let's say that, since my most recent build, there have been three (3)
> new commits.
> Rather than having one build that includes all three commits, I would
> like to have three separate builds; one for each of the three in sequence.
>
> Is anyone doing so
