You can also selectively not use zuul. For those jobs pointed at other source 
control, use standard Jenkins triggers, and all the rest of the tooling remains 
the same (including jjb for those new triggers.)


> On Oct 16, 2016, at 9:09 AM, Monty Taylor <> wrote:
>> On 10/14/2016 01:50 PM, Pradeep Patra wrote:
>> Hi all,
>> I was referring the CI system in OpenStack [1]. I was reading this
>> approach and its pretty good. One limitation I could find is the CI
>> mechanism is tightly coupled with git/geritt.
>> [snippet from [1]]
>> Zuul <> is a tool
>> that determines what jobs are run when. Zuul listens to the Gerrit event
>> stream, and first tries to match each event to one or more pipelines.
>> Is there a way to make Zuul listen to Code Collaborator or other Code
>> review tools events and the source control system is SVN not git?
> Hi Pradeep!
> Yes and no.
> Zuul is _heavily_ based around git. We have made a conscious decision to
> have that not be extensible so that we can make the best use of git
> under the hood. It's central to the way zuul prepares speculative future
> states to present to the testing system.
> On the other hand, zuul has a system of extensible Triggers and
> Reporters. Jobs can currently be triggered by both Gerrit and by
> cron-like timers. There is a set of patches proposed to add support for
> listening to github pull requests, although we're deferring landing them
> until we're a little further along with zuul v3. We have a desire for a
> "trigger from url" feature too - where zuul can watch for changes in a
> URL and trigger a job based on it.
> So it should be totally possible to write a Trigger and Reporter module
> to interface with Code Collaborator. I do not believe having such
> modules natively understand SVN will be possible.
> Monty
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack Development Mailing List (not for usage questions)

Reply via email to