[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Continuous Integration


Chronological Thread 
  • From: Chad Woolley < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Continuous Integration
  • Date: Thu, 8 Jul 2010 12:05:54 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=WwsnH6HPpxD7F7muNOLFZGhRf4a0JqXKabsa4kO/iizsWsTD2MoEn8CCUPo8zVJ0HN AbSCmp8b2K12ia/zVIzSjS9BVhWjO/QK1R+/IFJeuPj/KVa6Poom+OjplY48xNwRe2Ao JYvZPnAz7hzxRuzzuSgTbpZisrxJo6m1HW1tI=

On Thu, Jul 8, 2010 at 11:21 AM, Dreamcat4 
< >
 wrote:
> 1) Having some standard way of hooking into a chef run, so that once a
> change is commited to your git cookbooks, then a probably git post
> recieve hook can trigger the chef run, and the subsequent testing.
>
> As far as i know integrity continuus integration server would be the
> best tool for that job

Getting off topic, but I have to point out that git commit hooks are
fundamentally flawed for triggering CI builds.  If the request gets
dropped, or your CI server is down, you fail to build for that commit.
 If that commit broke the build, you never know until the next commit,
which could be much later.  Polling source control repo log is
failsafe, superior, and supported by all CI tools.

-- Chad



Archive powered by MHonArc 2.6.16.

§