directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: What shall CI be for / How make use of CI
Date Thu, 04 Sep 2008 10:15:25 GMT
Hi Felix,

comments inline

Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

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.

Does it make sense ?

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message