Drupal Automated Staging Toolkit

In the name of all Drupal developers testers and administrators we do solemnly swear. Amen.

This page will be the central location for all and sundry documentation for the Drupal Automated Staging Toolkit project - tutorial, user's guide, developer's guide, use cases, code examples, quick-starts, making money from home guides, and everything else related to DAST. Feel free to add or edit anything you find useful or in need of correction.
    Existing documentation from my posts on the SoC-2007 group and DAST wiki page will be incorporated here with links to the original articles. For now each section of documentation will reside on the central page but in future as the corpus of docs grows they may be broken into separate pages.
    This documentation is still a WIP so you will come across sections and even paragraphs that are missing or incomplete. Pleases bear with me as I write up the new docs and move the original docs from their home on d.o. and g.d.o

Contents

  1. Introduction and Overview
    1. Introduction
    2. Overview
    3. Motivations
    4. Research
    5. Phing
    6. Libraries and tools used
  2. Quick-Start
    1. A relatively simple build script - creating a patch test-bed
    2. A more complex example - creating a drupal.org clone using the drupalte
  3. User's Guide
    1. Running DAST
      1. Installation
      2. Requirements
      3. Startup
      4. Parameters
    2. The major components of a build script
      1. Diving into Phing I
      2. Diving into Phing II
    3. Properties - How to configure your build script
    4. The base build scripts:
      1. site-fetch.xml
      2. site-configure.xml
      3. site-patch.xml
      4. site-install.xml
      5. site-test.xml
    5. Writing your own build scripts
  4. Developer's Guide
    1. Extending Phing
    2. Wrapping new operations in tasks and types
    3. The DAST Phing extensions
      1. Types
      2. Tasks
    4. Example - the DrupalCVSTask element
    5. Unit tests

1. Introduction and Overview

1.1 Introduction   

    DAST is a PHP 5 CLI application for *nix/Windows for automating the installation tasks necessary to create an instance of the Drupal CMS on a server so that it is ready to be used for a particular purpose. We're not going to fight over synonyms - if staging == deploying == installing ok  - what we mean is you have a web server with PHP and a database server somewhere, anywhere, you have *nix shell account on or Windows command line access to the server, and you need to create a Drupal site. Maybe you're a developer and you need to create a site to develop a Drupal module that will make you rich and famous. Maybe you're a tester and you need to create a site to test the constant stream of patches from the Drupal development hives; or you need to duplicate an issue reported on a project you maintain. Maybe you're an administrator and you need to move an existing website from development to testing to production. Maybe you're just an end-user who wants to try-out a Drupal distro made with installation profiles like DrupalEd or drupalorg_testing . Maybe you're an infrastructure or high performance guru who wants to benchmark Drupal on different web server, PHP and database server configuration.

     There is a great deal of documentation on how to go about the process of installing Drupal. Normally you start from the installation guide and work from there. There is a great deal of know-how on what you you need to do - get the tarballs for the Drupal version you want to install or pull the code code directly from CVS; do the same for the modules you need and the installation profiles you want to use to tailor your site,  create a MySQL or PostgreSQL database;  create an Apache virtual host or IIS virtual directory... What doesn't exist is a way to specify the process of installing Drupal in a formal language which can be used by a tool to create an automated, self-documenting and reusasble, process,
and automate executing this process as many times as needed

From the project wiki:
Right now developing for Drupal requires a lot of manual tasks. If you're a developer or tester looking to run or test code on a particular Drupal site configuration i.e. specific versions of core or module or patches, specific server configurations, and a specific server location where you want to host the site - creating this site requires a lot of manual steps. Drupal developers have several scripts to automate part of these manual steps. DAST's primary objective is to standardize automating the Drupal build process, much like Ant does for the Java build process, or make for C/C++ projects.

DAST is a build tool. It's like Ant for Drupal. Actually it's a build process which will use an automated build framework like Ant to enable creation of a fully functional Drupal site, given the site's description and configuration specified in an XML build file. DAST is for developers and testers who need the ability to quickly build a Drupal site with specific versions of code and enabled modules, a specific app/database/web server configuration, staged to a specific server location. Right now, building a Drupal site is like building a C++ project, source file by source file, tool-by-tool from the command line. With DAST, developers can build and stage a site to a target physical or virtual server the same way they use make or Ant to build C++ or Java software.

 1.2 Overview

    DAST falls in the category of build utilities or build management tools (and hopefully manages to land on its feet.) It treats the steps required for creating a Drupal site like the steps for building a software project. You have set of components in different physical/conceptual locations that you need to pull together to produce a complete Drupal site. You don't want to keep doing it by hand - you want a script to automate the process of:
  1. Fetching the Drupal core code and module,  - maybe you just want to install the latest stable release or you maybe you need the latest CVS HEAD. You wish to specify the version of core to fetch and a list of modules to fetch.
  2. Configuring the web server, PHP and database server to host the Drupal site - This means at the very least creating a MySQL or PostrgeSQL database. You may also wish to create a new Apache virtual host and also enable or disable certain extensions in PHP
  3. Installing Drupal - Copy the core and module code to your new web site's physical directory, point the Drupal site database url to your newly created database. Then run the Drupal web installer to launch locale and profile installation.
  4. Patching Drupal - you may wish to apply a patch to resolve a known issue or as part of your testing activities.
  5. Testing Drupal - Unit tests are too cool for words. If you're testing patches or developing modules you might want to have a suite of unit tests to run to see if anything breaks functionality that's know to be working

You want a script to automate this and you want the script to be configured through variables so if you want to install Drupal-5.1 instead of Drupal 5.2 or HEAD you only need to change the variable that controls the revision, not the script or the process. You can repeat the process as many times as you like knowing that you will never forget any steps that can lead to a lot of time-wasting and head-scratching.

1.3 Motivation

  1. A key requirement of automated testing of Drupal is the ability to automate creating a Drupal site with a specific configuration. In the case of unit-testing module patches and code, and also for regression testing, the Drupal site must be built with specific versions of core and contrib- module code. There needs to be an automated way for a human tester or an automated testing tool to create a complete Drupal site by simply specifying what code versions he/she/it wants running, using some sort of interface or configuration file. The Drual testing framework SoC proposed project has this as a desired objective.

  2. For performance and scalability testing, a tester needs to vary web, database, and application server configuration parameters. A tester also needs to be able to quickly specify which Drupal modules will be enabled during the testing, well as quickly define a number of test users, and the size and nature of the sample content dataset.

  3. Once a Drupal site specification is created, it has to be staged to a physical server location. Testers need a way to automate the repetitive tasks of staging a Drupal site. Earl Miles (merlinofchaos) has already begun work towards this: http://drupal.org/node/52709

1.4 Research

There are three build frameworks I've done initial reading on: Ant[1], Ruby Rake[2] and Phing[3]. Ruby Rake is make done Ruby style, and is pretty interesting in its own right (much like Ruby itself) Martin Fowler wrote a great article on Rake[4] comparing it to other build tools and expounding on DSL - Domain Specific Languages[5], under which the whole family of build tool languages fall.

Ant
Ant is standard in the Java community. Ant is very powerful and extensible but it was designed for Java applications and requires full-blown Java code and an available Java runtime for defining and executing tasks and steps (Fowler describes Ant as an 'external' DSL[6] because the language used to code the build process in Ant's XML build file is separate from and is translated to the language which actually runs during the build process.

Rake
Rake is what Fowler calls an 'internal' DSL[7]. The language used to describe the build inputs, tasks, targets, outputs, dependencies,...are all defined in pure Ruby code. Rake is certainly capable of hosting DAST, but in order to use it you need to know Ruby and have Ruby available on the machine you're staging the site from.

[1] http://ant.apache.org
[2] http://rake.rubyforge.org
[3] http://phing.info
[4] http://www.martinfowler.com/articles/rake.html
[5] http://martinfowler.com/bliki/DomainSpecificLanguage.html
[6] http://martinfowler.com/articles/languageWorkbench.html#ExternalDsl
[7] http://martinfowler.com/articles/languageWorkbench.html#InternalDsl

 

1.5 Phing

Phing (http://phing.info) is the automated build tool used in DAST. From the Phing website home page:

PHing Is Not GNU make; it's a project build system based on Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make, and its use of simple XML build files and extensible PHP "task" classes make it an easy-to-use and highly flexible build framework. Features include file transformations (e.g. token replacement, XSLT transformation, Smarty template transformations), file system operations, interactive build support, SQL execution, CVS operations, tools for creating PEAR packages, and much more.

And from the Phing features page:

If you find yourself writing custom scripts to handle the packaging, deploying, or testing of your applications, then we suggest looking at the Phing framework. Phing can comes with numerous out-of-the-box operation modules (tasks), and an easy-to-use OO model for adding your own custom tasks.

Phing provides the following features:

* Simple XML buildfiles
* Rich set of provided tasks
* Easily extendable via PHP classes
* Platform-independent: works on UNIX, Windows, MacOSX
* No required external dependencies
* Built & optimized for ZendEngine2/PHP5

 


2. Quick-Starts

2.1 Creating a patch-testbed (The Great Use Case of '07)

    This article is to get you up-and-running with the motivation, concepts,  implementation,  and use of DAST through a step-by-step procedure for implementing a set of important use cases. I posted the first use case for DAST in the SoC 2007 group  - http://groups.drupal.org/node/4477 on June 8th 2007:

So I volunteered to help test the MSSQL database driver for 5.x and 6.x-dev. Right now Souvent22 is trying to stabilize the install script. So the routine for everybody is:

while (mssql install path != stable) {
1. Checkout DRUPAL-5-1 HEAD
2. Apply mssql patch
3. Delete all the stuff in the test vdir and put in the fresh HEAD
4. drop everything in the SQL Server test database
5. Go to Drupal install page
}

Now after a few iterations this is going to become tedious. So this is what will eventually replace it:

<?xml version="1.0"?>
<project name="Drupal-5-1 mssql driver install test" description="Test-bed for current mssql database driver" default="mssql-install-patch">

<target name="clean" description="Clean the Drupal 5 vdir and database">
<delete>
<!--Delete all files in web folder-->
<filelist dir="~/www/drupal5/mssqltest"/>
</delete>
<!--DROP the db and user-->
<SQLexec connectionstring="mssql://vanilla@ice@localhost/master" query="DROP Drupal-5-1-mssql-test" />
</target>

<target name="Drupal-5-1-HEAD-new-install" description ="Create fresh Drupal install with current 5-1-HEAD" depends="clean">
<!--Create the Drupal db and user and permissions with a file script-->
<SQLexec connectionstring="mssql://vanilla:ice@localhost/master" file="~/dbscripts/create-drupal-51-db.sql/">
<!--Checkout latest 5.1 HEAD-->
<CVS command="co" fromdir="pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal" todir="~/www/drupal5/mssqltest" revision="DRUPAL-5-1" module="drupal" />

<target name="Drupal-5-1-HEAD-mssql-patch" depends=Drupal-5-1-HEAD-new-install>
<!--Apply patch to new install-->>
<Patch options="Up0" dir="~/www/drupal5/mssqltest" patchfile="${patchfile}"
</target>
</project>

And that's all there is. Just run phing -Dpatchfile=whatever A completely automated and error-free repeatable way to test the patch. This is just the first set of tasks that could be automated. The remaining testing tasks:
6. go to site
7. select 'mssql' as database
8. set db options (db name, username, pass, port)
9. click install
10. See what happens next...
could also be automated using Phing's SQL and PHPExec taks. Even cooler, how about automatically running unit tests on the patch, and putting the results showing which tests passed and failed and why, in an HTML file. Implementing this use case is going to be one of the first major milestones in the DAST project.

This was the genesis of the core concepts in DAST - the whole project coalesces around 3 simple core concepts:
Lets jump into this use case. So you're part of the Drupal community and you would like to help out by testing core patches from the Drupal issue queue. In order to do so you need to setup a test environment to review patches. The nature of testing means you may have to setup and tear-down this test environment several times a day. You want to automate creating this patch test-bed.

The first HowTo was first posted to SoC-2007 on July 14th: http://groups.drupal.org/node/5124. The original HowTo is for for the 0.1.1 release only (DAST-5.x-1.1) in the Drupal project release nomenclature) but is not forward compatible with newer versions. Unless you have DAST-5.x-1.1 already installed you should use this updated HowTo for the 0.2 release and above.

The dast-patch build script automates the process of creating and patching a fresh Drupal site fetched from CVS. This is a step-by-step guide on using the build script to:
0. Clean the existing directory and database location you want to run the test site from;

1. Create the Drupal site database with the user and password you specify

2. Fetch core from CVS;

3. Fetch modules from CVS;

4. Create a MySQL database and user for the site;
5. Fetch a patch file from a URL and apply it to the Drupal site code-tree


Step 1: Install DAST. Download the d.o release package at http://ftp.drupal.org/files/projects/DAST-5.x-2.0.tar.gz. Download the dependencies package from http://www.abeharry.info/stuff/dast-deps.tar.gz or http://www.abeharry.info/stuff/dast-deps.zip. and unpack them to the same dir - /usr/share/DAST for example. There are no additional dependencies besides PHP 5.2.x, cvs, wget, and patch. The directory you unpacked the release and dependencies package becomes your DAST_HOME


Step 2: Set your properties. Each build script comes with one example properties file, in both a *nix and Windows flavour. The *nix sample properties file for dast-patch is dast-patch-nix-sample.properties and for Windows dast-patch-windows-sample.properties. Copy this to dast-patch-base.properties and edit this file to configure the build with the following properties (comments delimited with #, replace ? with your values):


#Name of the patch file to apply (REQUIRED):
patch.file = ? #e.g 151394-2.patch

#The full HTTP Url of the patch file, used if patch.method = HTTP:
patch.Url = ? #e.g. http://drupal.org/files/issues/151394-2.patch

#The directory which will contain the Drupal code to be patched:
drupal.dir = ? #e.g. /var/www/drupal51-dev/dast/test

#The Url of the newly created Drupal site  (must include trailing slash if no file specified)
drupal.Url = ? #e.g. http://localhost/drupal51-dev/dast/test/

#The RDBMS which will host the Drupal site database
drupal.database.driver = ? #e.g. mysql

#The name of the server which will host the database - this name is RDBMS specific, e.g MySQL uses simple
#hostnames while MSSQL mau use aliases defined in the MSSQL client setup, Oracle may use TNSNames...
drupal.database.host = ? #e.g. localhost

#The name of the database to create which will be used by the Drupal site
drupal.database.name =? #e.g. DRUPAL51

#The database user which will be used by the Drupal site
drupal.database.user = ? #e.g.joe

#The host that the user will be connecting from
drupal.database.user.host = ? #e.g. localhost

#The password for the database user which will be used by the Drupal site
drupal.database.user.pass = ? #e.g. cool

#The name of the user which will be used to run the DROP/CREATE script to (re)create the Drupal database and user
#The user account must have sufficient rights to perfom the operations in this script
drupal.database.CreateScript.user = ? #e.g. root

#The password for the drupal.database.CreateScript.user
drupal.database.CreateScript.user.pass = ? #e.g.root

#The database where the ceate script will be executed, e.g. mysql in MySQL or master in MSSQL
drupal.database.CreateScript.name = mysql

#CVS Branch/Tag revision of core to retrieve
drupal.core.Cvs.Revision = ? #e.g. DRUPAL-5-1

#The list of modules to retrieve from the directory/CVS contrib- repository - comma delimited.
drupal.modules.list=? #e.g. devel,simpletest,ulink

#CVS Branch/Tag revision of modules to retrieve
drupal.modules.Cvs.Revision = ? #e.g. DRUPAL-5



Step 3: Test the build script From the root directory where you uncompressed the dast package:

./bin/dast -f dast-patch.xml configure
This will run the configure task which will verify that Phing can be bootstrapped and that all required properties for the dast-patch build are present. (This isn't like autoconf configure - nothing is written to disk.)


Step 4: Run the build script From the root DAST directory:
./bin/dast -f dast-patch.xml

If all goes well you should have a fresh Drupal site patched and ready for testing.
All properties defined in a file can be overridden using the -D switch at the command-line, e.g.

./bin/dast -f dast-patch.xml -D"patch.method=skip"

To use a local patch file at patch.file.path You can also specify a logfile to store all output using the switch -f
You can also call most tasks individually -e.g ./bin/dast -f dast-patch.xml clean

For all the properties and tasks you can use to tailor the build see the - *-sample.properties and check README.txt for usage and any general questions.


These are the required properties, the rest can be left at the default for the first run. And that's it, the script will go out and fetch the required components and assemble them into a working Drupal site ready for patching. You can change the patch.* properties to download and apply another patch and change the drupal.core.Cvs.Revision and drupal.modules.Cvs.Revision to fetch different versions of Drupal. You can opt to install Drupal using a local source dir by changing drupal.core.method and drupal.modules.method to directory. You can also run individual sections of the script, for example run the clean target by invoking: /bin/dast -f dast-patch.xml clean to drop and recreate the Drupal database and directory.

2.2 A more complex example - creating a drupal.org clone using the drupalorg_testing profile

Although this example is labelled complex, it really isn't that - most of the properties for the build project can be left at their defaults. You are only required to fill in the filesystem and database locations you want the Drupal site installed. This site will be based on the the drupalorg_testing installation profile created by Derek Wright (dww). This profile installs all the modules used by the drupal.org site and creates some test data. It is intended for use by d.o admins who need to test upgraded modules and other changes before they are pushed to the live d.o site. This build project downloads the 5.2 core, the modules required by the profile, and the profile itself, creates the database and calls the installer Url so at the end of the build you have a clone d.o site up and ready for testing.

Step 1: Install DAST. (If you haven't already) Download the d.o release package at http://ftp.drupal.org/files/projects/DAST-5.x-2.0.tar.gz. Download the dependencies package from http://www.abeharry.info/stuff/dast-deps.tar.gz or http://www.abeharry.info/stuff/dast-deps.zip. and unpack them to the same dir - /usr/share/DAST for example. There are no additional dependencies besides PHP 5.2.x, cvs, wget, and patch. The directory you unpacked the release and dependencies package becomes your DAST_HOME


Step 2: Set your properties. The build project for this example lives in DAST_HOME/projects/drupalorg_testing-site. The properties file you will be editing is named drupalorg_testing-site-base.properties The only properties you need to consider are the following:

3.2 The base build scripts

1. site-fetch.xml

*Description: This script fetches Drupal core and contrib-module code. It supports CVS and local source directory locations. You specify the CVS revision of the core you wish to download (other CVS parameters like CVSROOT are also configurable but usually the default values will suffice for the vast majority of the cases,) a list of modules you want, and their CVS revisions, and the script will connect to the Drupal CVS repository and export or checkout the requested code to your local dir. You can also use as a source for the Drupal code a local directory to avoid the overhead of fetching from CVS every time.

*Functions Use this script to:
*Targets: configure, clean, fetchCore, fetchModules, main, dump-config .
*Behaviour:
  1. Execute public target configure:
    1. Load base properties file ${basePropertiesFiles} (default=site-fetch-base.properties} and user properties file ${propertiesFile} (default=site-fetch.properties)
  2. Write logs to ${build.log.defaultdir} (default=/var/log/DAST or E:\var\log\DAST)
  3. If ${build.run.clean} == yes (default) execute public target clean:
    1. Clean target deletes all files and dirs in ${drupal.dir}
  4. Execute target fetchCore:
    1. If ${drupal.core.method} == CVS (default)
      1. Verify required drupal.core.Cvs.* properties are present  and fill in default values for optional properties
      2. Checkout/export Drupal core from CVS into ${drupal.dir}
    2. If ${drupal.core.method} == directory) then copy files from ${drupal.core.sourcedir} into ${drupal.dir}
    3. If
  5. If ${patch.method == file then copy ${patch.file.path} to ${dast.ext.patch}
  6. If ${patch.method} == file then HTTP GET ${path.url} and save to ${dast.ext.patch}
  7. exec patch -d "${drupal.dir}"  -${patch.options} < "${dast.ext.patch}${php.directory_separator}${patch.file.path}" -b  in directory ${drupal.dir} with <stdout> = ${build.log.defaultdir}${php.directory_separator}dast-patch-patch-output.log and <stderror>=${build.log.defaultdir}${php.directory_separator}dast-patch-patch-error.log
  8. The rejects will be found in the same dir as the files to be patched i.e. drupal.dir. You may wand to do a recursive search for all .rej files to verify your patch was accepted

.

2. site-configure.xml

*Description: This script configures the web server, database server ,PHP and application server on which the Drupal site will run.

*Functions Use this script to:

*Targets: configure, configure-create-database, create-database, configure-create-apachehttpdsite, create-apachehttpdsite, configure-create-php-configuration, create-php-configuration, configure-createappserver-sonfiguration, create-appserver-configuration.

*Behaviour: Unlike site-fetch.xml, site-configure does not rely exclusively on properties for its behaviour - the user must write their own actions depending on what configuration changes they wish to make. Properties are used for the values of the configuration directives but what how and where are these configuration directives is determined by the user. An example: consider the site-configure script below:

<project name="site-configure" default="main" basedir="../>

...

  <!-- =================================
          target: create-apachehttpd-site             
         ================================= -->
  <target name="create-apachehttpd-site" depends="configure-create-apachehttpd-site"
    description="--> This task will create a new Apache httpd site; modify the files and directives written here to suit your httpd setup ">
    
  <!--Add the port for the our site vhost to ports.conf -->
  <ApacheHttpdConf File="${apachehttpd.ports.conf}">
    <ApacheHttpdConfDirective DirectiveName="Listen" DirectiveContent="${apachehttpd.site.port}" DirectiveOverwrite="no"/>
  </ApacheHttpdConf>
   
  <!--Make sure the vhost configs in sites-enabled dirs is being pulled in in apache2.conf -->
  <ApacheHttpdConf File="${apachehttpd.apache2.conf}">
    <ApacheHttpdConfDirective DirectiveName="include" DirectiveContent="${apachehttpd.sites-enabled.dir}" DirectiveOverwrite="no"/>
  </ApacheHttpdConf>  
     
  <!--Create the vhost in a conf file in "${apachehttpd.site.vhost.conf} -->
  <ApacheHttpdConf File="${apachehttpd.site.vhost.conf}">
    <ApacheHttpdConfSection SectionType="VirtualHost" SectionName="*:${apachehttpd.site.port}" File="${>
      <ApacheHttpdConfDirective DirectiveName="ServerAdmin" DirectiveContent="${apachehttpd.site.vhost.ServerAdmin}" />
      <ApacheHttpdConfDirective DirectiveName="DocumentRoot" DirectiveContent="${apachehttpd.site.vhost.DocumentRoot}" />
      <ApacheHttpdConfDirective DirectiveName="ServerName" DirectiveContent="${apachehttpd.site.vhost.ServerName}" />
      <ApacheHttpdConfDirective DirectiveName="ErrorLog" DirectiveContent="${apachehttpd.site.vhost.ErrorLog}" />
      <ApacheHttpdConfDirective DirectiveName="CustomLog" DirectiveContent="${apachehttpd.site.vhost.CustomLog}" />
    </ApacheHttpdConfSection>
  </ApacheHttpdConf>
      
    </target>

In this script we are creating a new Apache virtual host. We first add a port for httpd to listen on which is where we'll put our vhost for our Drupal site. We then add misc. directives for the vhost, followed by configuration of the actual Drupal site directory.

#The method to fetch the patch file - if HTTP then the patch will be downloaded from patch.Url; if file
#then patch.file will be used. If skip, then Drupal won't be patched  (REQUIRED)
patch.method = HTTP
#Name of the patch file to apply (REQUIRED):
patch.file = 151394-2.patch
#Command-line options passed to the patch command. (REQUIRED)
patch.options = p0
#The full HTTP Url of the patch file, used if patch.method = HTTP:
patch.Url = http://drupal.org/files/issues/151394-2.patch
#The full absolute location of the patch file on the filesystem, used if patch.method=file:
patch.file.path = E:\My Documents\Web Development Projects\Drupal\Patches\151394-2.patch 
#The directory which will contain the Drupal code to be patched: (REQUIRED)
drupal.dir = E:\Webs\drupal-510\dev\dast\test

 




3. site-patch.xml

*Description: This script applies a patch file using the patch command to a Drupal site code-tree. It saves the output chunks of the patch process in the #{dast.ext}/patch directory. You specify the patch file, the url or directory to fetch it from, and the options you want the patch command to use: the default is -p0
*Targets: configure, fetch-patch, exec-patch, main
*Behaviour:
  1. Loads base properties file ${basePropertiesFiles} (default=site-patch-base.properties} and user properties file ${propertiesFile} (default=site-patch-user.properties)
  2. Defines ${dast.ext.patch} = ${dast.home}${php.directory_separator}ext
  3. Writes logs to ${build.log.defaultdir} (default=/var/log or E:\var\log)
  4. If ${patch.method} == HTTP (default) then wget ${path.url} and save to ${dast.ext.patch}
  5. If ${patch.method == file then copy ${patch.file.path} to ${dast.ext.patch}
  6. If ${patch.method} == file then HTTP GET ${path.url} and save to ${dast.ext.patch}
  7. exec patch -d "${drupal.dir}"  -${patch.options} < "${dast.ext.patch}${php.directory_separator}${patch.file.path}" -b  in directory ${drupal.dir} with <stdout> = ${build.log.defaultdir}${php.directory_separator}dast-patch-patch-output.log and <stderror>=${build.log.defaultdir}${php.directory_separator}dast-patch-patch-error.log
  8. The output of the patch execution will be found in ${dast.ext}/patch. The originals and rejects will be found in the same dir as the files to be patched i.e. drupal.dir. You may wand to do a recursive search for all .rej and orij files to verify your patch was accepted
*Properties

#dir for DAST log files (REQUIRED)
build.log.defaultdir = E:\var\log\DAST

#The method to fetch the patch file - if HTTP then the patch will be downloaded from patch.Url; if file
#then patch.file will be used. If skip, then Drupal won't be patched  (REQUIRED)
patch.method = HTTP

#Name of the patch file to apply (REQUIRED):
patch.file = 151394-2.patch

#Command-line options passed to the patch command. (REQUIRED)
patch.options = p0

#The full HTTP Url of the patch file, used if patch.method = HTTP:
patch.Url = http://drupal.org/files/issues/151394-2.patch

#The full absolute location of the patch file on the filesystem, used if patch.method=file:
patch.file.path = E:\My Documents\Web Development Projects\Drupal\Patches\151394-2.patch 

#The directory which will contain the Drupal code to be patched: (REQUIRED)
drupal.dir = E:\Webs\drupal\dev\dast\test


*Example
In this case we're downloading the 151304-2.patch from the Url and applying it to the site at /var/www/drupal-52....

3. site-install.xml

*Description: This script runs the final installation steps after the Drupal site-code is in place and patched if needed, and the server hosting the Drupal site has been configured. In a typical build project this would be the fourth of the base build scripts used. site-install.xml sets the $db_url variable to point to the database to be used by Drupal, downloads if required the profile
*Targets: configure, fetch-patch, exec-patch, main
*Behaviour: