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 Sat, 01 Mar 2008 22:15:19 GMT
On 01/03/2008, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
>
>  On Sat, Mar 1, 2008 at 3:40 PM, sebb <sebbaz@gmail.com> wrote:
>  > On 01/03/2008, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>
> >  >  Continuous integration tools would probably be worth a whole topic of
>  >  >  their own, but since they are related to version control I'm taking
>  >  >  them up within this scope as well.
>  >  >
>  >  >  Use case: Someone (either within or outside Apache) sets up a
>  >  >  continuous integration system and wants to get the latest sources from
>  >  >  the source repository. Optimally the system would automatically
>  >  >  compile, package, and test the sources after each commit, but hourly,
>  >
>  >  Related changes are not always packaged into a single commit.
>  >
>  >  Sometimes it is easier to use several commits; though hopefully each
>  >  one will be self-contained, i.e. will not break the build.
>
>
> Sure, but that's IMHO related to the sequence of changes use case, and
>  from a purist perspective such changes would probably be best handled
>  through a short-lived development branch. And ideally such changes
>  could then be merged back to trunk as an atomic commit that still
>  preserves the full incremental change history.
>
>  The exact commit and consistency rules are of course up to each
>  project to decide for themselves, but there are a number of projects
>  with a policy that no commit should break the build. The more
>  frequently the CI system runs, the less chance there is for another
>  developer to stumble on a broken build.
>
>
>  >  If there are 10 commits in as many minutes, does the CI system really
>  >  need to build each one?
>
>
> It wuold IMHO be very useful to have clear indication of which one of
>  those 10 commits actually broke the build.

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.

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.

>  BR,
>
>
>  Jukka Zitting
>

Mime
View raw message