Emmanuel Lecharny schrieb: > 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.
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 ? >
