• 2009-01-15

    Abstract SimpleTest browser holds many possibilities: install and update scripts

    Situation The SimpleTest browser that is included in the Drupal 7 core is very powerful and I have found myself hacking in order to use it outside of SimpleTest on a number of occasions, as have others. In addition the DrupalWebTestCase is becoming rather bloated. There is an issue to create pluggable backends for drupal_http_request which could be cleanly done by abstracting the SimpleTest browser. The change would create a clean and more powerful API as well as open up a number of possibilities by having a browser built into Drupal core and thus is something worth working on.

    Solution A while back I did some work towards abstracting the SimpleTest browser, not only out of DrupalWebTestCase, but improving/cleaning the code and writing it with a pluggable backend layer. The code is quite far along and just needs a bit more refinement before it can replace the existing SimpleTest browser. The next step would be to replace drupal_http_request or make it a wrapper. After that, areas of core that parse HTML and such can be cleaned up and simplified using the browser.

    Possibilities With a browser in core there are a number of powerful tools that can very easily be added. For instance install and update scripts that can trigger remote servers!! Think of having a single script on a development machine that runs the update script on all specified sites!

    Installing via a script can be very usefull not only for the obvious, but also for modules like the Usability Testing Suite and Project Issue File Review that have to make separate installations of Drupal and currently must maintain their own install scripts. Having an abstracted installation script is necessary for testing.drupal.org to be able to function with patches that make changes to the installer.

    I plan to work on this further, but have been busy with other projects lately and my recent video card experience. I would like to hear some feedback from the community and possibly recruit some help.

    Related issues

  • 2009-01-11

    Back

    I have been out of commission for about 10 days. I a new graphics card (and other internals) and have a partially setup development environment.

    I lost certain date in the transition (some of which is vital to my Drupal work) so I will be working to get everything going again.

  • 2009-01-04

    Blind, but soon I will see

    The graphics card on my development machine died New Years Eve and thus I am without a development environment for the time being. I will order a new graphics card and a few other parts today or tomorrow so I should be back in business within the week.

    Sorry for any delays in development.

    Thanks for the support. (chx has graciously donated to my cause. :) )

  • 2008-12-27

    Automated Testing System Development Clarification

    For posterity: http://widget.chipin.com/widget/id/d6208430185ee1a5

    After my most recent post concerning the Testbed design change and development I received a number of comments that lead me to believe that the post was misunderstood. The comments suggest that the readers believe my primary focus of development will be changing from a push to a pull model. The post seems to have been misleading in that regard.

    The change to a pull architecture is a very minor change in terms of coding, only 2 functions are even effected, but in terms of managing the network it helps out a lot. The majority of the development, that I am raising $3000 for, will be focused on implementing the ideas described in The Future of Automated Patch Testing. The feature additions will:

    • Give more control to server administrators (donated servers)
    • Make it easier to manage the automated testing framework
    • Allow for testing of multiple environment configurations
    • Open up testing of Drupal 6 core and contrib code.

    I hope this has cleared up any misconceptions with the automated testing system as it stands and my plans for its feature.

    I appreciate any donations.

  • 2008-12-20

    Testbed design change and development

    For posterity: http://widget.chipin.com/widget/id/d6208430185ee1a5

    Please see clarification.

    The next goal for the testing system (centered at testing.drupal.org) is to test Drupal 6, Drupal 6 contrib, and eventually Drupal 7 contrib. This will require:

    • Additional testing computers to be added to the current fleet of 4-6 servers which handles the Drupal 7 core load
    • Re-architecting the automated testing system as described below
    • The addition of new features described in my previous post, The Future of Automated Patch Testing

    In order for me to be able to devote significant resources in the short term to get this completed it would very helpful to have funding. I would like to raise $3,000 for the development of the new system.

    Before describing the details of the new system, lets look at how the current system works.

    Current system

    System flow

    The automated testing system has three stages, or sections, to it. The sections are illustrated in the figure to the right, but I’ll give an overview of what they do.

    1. The project server that manages all the issues related to projects. - drupal.org
    2. The testing master server which distributes the testing load and aggregates the results to the appropriate project server. - http:testing.drupal.org
    3. The testing server that performs the patch review and reports back to the master server. - network of servers

    New architecture

    The automated testing system is classified as a push architecture. That means that the testing master server pushes (ie. sends) patches to each of the testing servers. The new architecture will be based on a client/server model where the test client pull (ie. request) patches to test from the server.

    In addition to changing the basic architecture of the system the large feature list will also be implemented. After all is said and done the new system will provide a more powerful tool to the Drupal community.

    Reasoning

    The motivation for making the change is due to the difficulties we have run into while maintaining the system for the last few weeks.

    • Adding a testing server requires the entire system to be put on "hold".
    • There is not an automated way to confirm that a testing server is functioning properly.
    • When a testing server becomes "messed up" or "un-reachable" the system does not automatically react.
    • Server administrators cannot simply remove their server from the fleet; they must first inform us that they are doing so.

    All this manual intervention adds up to a large amount of time that Chad “hunmonk” Phillips and I have to spend to keep the system running smoothly. As we look to add more servers our time commitment will increase to the point where it is not feasible to maintain the system, thus the changes are required.