www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [scm] Use case: Continuous integration
Date Sun, 02 Mar 2008 11:31:41 GMT
On 02/03/2008, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
>
>  On Sun, Mar 2, 2008 at 12:15 AM, sebb <sebbaz@gmail.com> wrote:
>  >  Not entirely sure why one should care about temporary build failures,
>  >  unless one is trying to find out which committers are not adhering to
>  >  the rules.
>
>
> In many case developer time is much more valuable than computing time,
>  so a CI system that can quickly and accurately point out a build
>  failure can easily save time and improve productivity.

Surely that is only of use if the build failure has not already been
resolved by a later commit?  For example, it's quite easy accidentally
to omit a new file from a commit; this will normally be spotted
quickly afterwards, and then the missing file can be committed.

Not ideal of course if someone else happens to update in between, but
not really a big problem either as it will be immediately obvious when
the CI system is checked and the later build is OK.

>  That may not be a key priority for the ASF itself, but it can be quite
>  valuable to many companies that have people actively working on Apache
>  projects. If they provide the required CI machinery, what can we do on
>  the SCM side to enable optimum usage of such resources?
>
>
>  >  Also, it seems to me that this may not scale well - the average time
>  >  between commits can easily exceed the time to perform a build.
>
>
> A reasonable system would of course queue the change notifications and
>  process them one at a time. The average commit frequency will hardly
>  overload a decent CI server, and any backlog acquired during commit
>  peaks will probably be soon resolved.
>
>  This is probably also something that should be taken into account with
>  frequently running pull-based CI servers as well. At least I've seen
>  complaints about multiple CI builds stacking up when the build time
>  exceeds the poll frequency.

Or exceeds the pushed commit messages ...

>  BR,
>
>
>  Jukka Zitting
>

Mime
View raw message