Looking towards a Builder parade and QA

Colin Clark colinbdclark at gmail.com
Thu Dec 3 19:41:51 UTC 2009

Hi Laurel,

On 2-Dec-09, at 3:35 PM, Laurel A. Williams wrote:
> I would like to promote: http://issues.fluidproject.org/browse/FLUID-3162 
>  to a blocker. I would like to chat with you about approaches to this.

Makes sense to me.

> Quick fixes:
> http://issues.fluidproject.org/browse/FLUID-3395 - user friendly  
> error messages
> http://issues.fluidproject.org/browse/FLUID-3396 - rename files to  
> InfusionBuilder. I notice that the project in the SVN incubator  
> directory is also called CustomBuild. Can I change that or does  
> someone else have to do that?

You can change this yourself.

> http://issues.fluidproject.org/browse/FLUID-3126 - load testing - it  
> may be worth re-running these tests, what do you think?

Yes, I agree. It would be good to run them, and record the stats in  
the wiki.

>> * Any thoughts on ways we might automate the cache priming process?  
>> A script using curl? A little web page that makes Ajax requests to  
>> the Builder?
> http://issues.fluidproject.org/browse/FLUID-3399
> The first option was what I had in mind. Maybe we can discuss the  
> second option more. Another thought might be to add the cache  
> priming tasks to the ant deploy script.

Yesterday we chatted in person about a variety of options we could  
use, but the most promising seem to be either the Web page or a script  
using curl. However, Michelle pointed out that we can probably make  
some tweaks to the build script in order to make the minification step  
a one-time activity. Since it appears to be minification that is most  
CPU intensive, if we can take that step out of a dynamic build, we'll  
be feeling a lot less pressure to comprehensively prime the cache  
before releasing.

You're going to look into that over the next few days, right?

>> * I'm thinking we might be able to whittle the deploy steps down to  
>> one if we created a little shell script that runs each of the first  
>> six steps outlined in your documentation, prompting the user to  
>> supply the DB username and password. What do you think?
> Doable, but some questions come to mind. Where do we keep the script  
> and does the "deployer" need to check it out and chmod it to run  
> it ? That cuts down on the number steps but not very much. Also  
> would we require users to ssh into the server before running the  
> script? I can see some issues running such a script from a windows  
> environment (ssh, cygwin, etc). I thought about adding some of these  
> steps to the ant script but ended up not doing it A) because if the  
> script is stored in the SVN then the export step 2 has to be  
> executed anyway but for fewer files and B) because you can't delete  
> the directory containing the ant script as part of the ant script  
> <grin>. I know realistically there are ways around both those  
> issues, but never really convinced myself of the benefit.

I was thinking that the process was simple enough that we could simply  
have a script that lives on the server itself, and checked into SVN in  
our infrastructure space just to ensure it doesn't get lost. Should be  
pretty simple.


Colin Clark
Technical Lead, Fluid Project

More information about the fluid-work mailing list