directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <>
Subject Re: What shall CI be for / How make use of CI
Date Thu, 04 Sep 2008 10:28:16 GMT
Emmanuel Lecharny schrieb:
> Hi Felix,
> comments inline
> Felix Knecht wrote:
>> Hash: SHA1
>> Hi all
>> Following the 'Studio breakage fixed?' thread we should decide about
>> how to use the CI builds for. ATM the projects are
>> build (every 30 minutes) but only if there are svn changes made to
>> the specific project. 
> I think this is good.
>> Doing so there can be a big
>> delay before noticing the a e.g. change in shared have impacts on
>> apacheds/studio/... It will be noticed next time
>> apacheds/studio/... is built. This will in most cases happen when a
>> commit is done to one of those projects and not earlier.
>> We can change this by forcing CI to build the project each time
>> regardless of the latest build state (ok, failed, ...).
> Well, the recent problem we had (studio breakage due to shared being
> modified) were pretty much due to some laziness and misunderstanding
> of my part. First, I forgot to check that the part IO modified in
> shared impacted or not studio. This is for the laziness part. Then,
> yesturday, after having done some more modification, I did check that
> studio was running fine, and it did... until the next 30 minute CI
> build :). The reason is that the way Studio is build was badly
> understood by me : I thought that studio was using the local snapshots
> first, and then look up on the remote repo. Bad bad bad : this is not
> the case. So when I did my first build, it took the oxylos shared
> jars, and all went ok. But as I modified shared, those snapshots were
> modified, and broke the build.

Hmmm. Normally when using snapshots it takes the latest it can find, no
matter if it's a local or a remote snapshot. Maybe this is a time
problem between your pc and the CI server or the CI server did a '30 min
build' in between.

> Ok, now, what can we do to avoid such problems :
> 1) being less lazzy. Working on it ;)
> 2) the local build should check if there are not more recent local
> snapshot before switching to the repo's snapshot. Doing so will allow
> us to check that the modifications are ok, and don't break the build.
>> Doing so I'd suggest changing the build schedule per project at
>> maximum twice a day. Otherwise will run probably into a
>> queueing problem because projects are still in build process while
>> already beeing queued again.
> I would rather keep the current system. it's working well,

> and assuming you are not committing and running to bed, you have 30
> minutes to fix the potential breakage.
No, in some case you'll not get the error. Think about following situation:
Studio builds well. you do a change on the shared (which breaks studio),
check it in and wait another 30 minutes. Studio will not be build until
somebody does a checkin on studio -> studio will not break in the next
30 minutes.

> Does it make sense ?

View raw message