Looking towards a Builder parade and QA
colinbdclark at gmail.com
Thu Dec 3 19:41:51 UTC 2009
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
>> * 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?
> 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
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
Technical Lead, Fluid Project
More information about the fluid-work