FLUID-3427: At the moment, the PHP and JavaScript unit tests for Infusion aren't publicly visible on the daily build

Description

Since we're using the standard deploy task, we're currently pruning out the JavaScript unit tests so that they're not visible on the daily build server. We also have the PHP tests outside of the public space, so they're not visible either. Steps to fix:

1. Parameterize the unit test pruning action from the current deploy script so that it is an optional phase
2. Restructure the current directory layout so that the PHP unit tests are web-visible by default
3. Extend the test pruning target to also prune out the PHP tests upon deploy

Attachments

• FLUID-3427-1-patch.txt

Comments

• Justin Obara commented 2009-12-11T13:58:06.000-0500

  Bug Parade Builder 1.1.2

• Laurel Williams commented 2009-12-14T11:18:34.000-0500

  php unit tests are now available at:
  http://forge.fluidproject.org/infusionBuilder/tests/php/PostClassTest.php
  http://forge.fluidproject.org/infusionBuilder/tests/php/ModuleClassTest.php
  http://forge.fluidproject.org/infusionBuilder/tests/php/BuilderUtilitiesClassTest.php
  http://forge.fluidproject.org/infusionBuilder/tests/php/GroupClassTest.php

  js unit tests are available at:
  http://forge.fluidproject.org/infusionBuilder/tests/html/InfusionBuilder-tests.html

• Colin Clark commented 2009-12-14T17:50:44.000-0500

  Here's a correct URL to the BuilderUtilities test:

  http://forge.fluidproject.org/infusionBuilder/tests/php/BuilderUtilitiesTest.php

• Colin Clark commented 2009-12-14T18:02:54.000-0500

  I've reviewed all of Laurel's changes to the tests and the Ant deploy script for this issue, and they look good with one exception.

  Looking at the dependencies for the "daily" target, I notice that we depend on another target that backs up an old version of the Builder before proceeding with the deployment. I can see how this is very useful for real production builds--always keep a copy of the old, working version around while deploying a new version. But for a daily build, I wonder if this is necessary? Seems like one place where extra backup cruft will accumulate, forgotten?

  Thoughts?

• Colin Clark commented 2009-12-15T12:21:50.000-0500

  I've reviewed Laurel's third revision to this issue, which includes backups for the deploy stage but not the daily build, and it looks good. Good to go for the Builder 1.1.2 release.