This sourceforge.net project aims to be a repository for useful CruiseControl.NET PlugIn's
This plug in is a source control filter. The primary use is to filter other CCNET source control modifications to only detect the changes that are of interest. Examples of this might be looking for changes in the file system of only a single file, or a handful. This was created because the native CCNET filtered source control is not fully ant compliant.
The name of the source control is pathfilter. This name is used where you specify a type in the CCNET xml configuration. When using the path filter in the sourcecontrol project element, use type="pathfilter". When using path filter as part of a multiple source control, use
There are four attributes of a path filter. The provider element is required and specifies the root ccnet source control provider being filtered. The includes and excludes elements specify a list of path patterns. The caseSensitive element specifies if the patterns are case sensitive or not. The default behavior is to include all files and folders that are detected by the source control provider.
There are three special character sequences that are used to in the path patterns. The '**' sequence specifies that zero or more paths. The '*' sequence matches any portion of a path or file name. The '?' matches a single character in the path or file name. The Apache Ant documentation on this topic is at the following link: Ant Patterns
The following configuration uses pathfilter as the only ccnet source control provider. This configuration uses the file system source control provider, and looks for changes to a file called Foo.dll, located in the folder artifacts. In this case, the artifacts folder can have any number of parent folders.
<sourcecontrol type="pathfilter">
<provider type="filesystem">
<repositoryRoot>/workingdir</repositoryRoot>
</provider>
<includes>
<pattern>**/artifacts/Foo.dll</pattern>
</includes>
</sourcecontrol>
The following configuration uses the multiple source control as the ccnet source control provider to combine changes detected by a cvs source control provider, and detected changes to the same Foo.dll described above.
<sourcecontrol type="multi">
<sourceControls>
<cvs autoGetSource="true">
<executable>/devtools/ccnet/cvswithplink.bat</executable>
<workingDirectory>SomeProject</workingDirectory>
</cvs>
<pathfilter>
<provider type="filesystem">
<repositoryRoot>/workingdir</repositoryRoot>
</provider>
<includes>
<pattern>**/artifacts/Foo.dll</pattern>
</includes>
</pathfilter>
</sourceControls>
</sourcecontrol>
The sequential task plug in is used to single thread tasks across projects. It works by locking an operating system mutex before executing a set of configured tasks. The name of the lock can be specified when declaring the sequential task. This is used when multiple projects in the same CCNET server can detect changes and launch their build process. This can overwhelm a machine if to many builds are running.
The name of the task is sequential. The name is used when specifing types in a task block. The sequential task has a lockName attribute. When specified, the lock name is used instead of the default of 'SequentialGlobalMutex'. When two sequential tasks share lock names, the will execute using a first come first serve basis. For each task, specify a task element inside of the sequential element.
The following configuration ensures that the nant task and teh null task are run sequentialy under the lock name of SequentialGlobalMutex. This is an example of configuring allowing an array of tasks to be included. This is the preferred form of configuration.
<sequential>
<tasks>
<nant>
<executable>tools/nant/NAnt.exe</executable>
<baseDirectory>nantbuild</baseDirectory>
<nologo>true</nologo>
<buildFile>Foo.build</buildFile>
<targetList>
<target>clean</target>
<target>coverage</target>
</targetList>
</nant>
<nullTask />
</tasks>
</sequential>
The following configuration ensures that the nant task is the only one running under the lock name of SequentialGlobalMutex. This is an example of configuring using a single task. This form of configuration is obsolete in favor of allowing an array of tasks. This configuration sample previously had a bug in it showing the ability to have multiple tasks under a single sequential task. If you need this style of configuration see the configuration above.
<sequential>
<task type="nant">
<executable>tools/nant/NAnt.exe</executable>
<baseDirectory>nantbuild</baseDirectory>
<nologo>true</nologo>
<buildFile>Foo.build</buildFile>
<targetList>
<target>clean</target>
<target>coverage</target>
</targetList>
</task>
</sequential>
The sequential source control plug in is used to single thread source control access across projects within the same ccnet server. It works by locking an operating system mutex before executing the configured source control providers. This source control plug in is a drop in replacement for the multi source control provider.
Read the multi source control instructions replacing the type name with sequentialSource. The following example does exactly that with the example from the Ant Path Filter.
<sourcecontrol type="sequentialSource">
<sourceControls>
<cvs autoGetSource="true">
<executable>/devtools/ccnet/cvswithplink.bat</executable>
<workingDirectory>SomeProject</workingDirectory>
</cvs>
<pathfilter>
<provider type="filesystem">
<repositoryRoot>/workingdir</repositoryRoot>
</provider>
<includes>
<pattern>**/artifacts/Foo.dll</pattern>
</includes>
</pathfilter>
</sourceControls>
</sourcecontrol>
The sequential project plug in takes the idea of sequential to the container level. This plug in is used to configure projects that should be single threaded across projects within the same ccnet server. It works by locking an operating system mutex before executing a build operation on the project. This plug in is a drop in replacement for the project element in a CCNet configuration. This plug in is designed to cooperate with the sequentail task and sequential source control plug-in's in two ways. The first is that this plug-in can use the same lock as the sequential task and sequential source control plug-in's. In fact, the sequential project uses the same default lock name as the two other plug-in's. The second is to ensure that only a single build is running for the project at any given time. The second is accomplished by giving the project a unique lock name, but leaving the sequential task and sequential source plug-ins with the same lock name.
The sequential project plug in holds the lock while the following operations on a the project take place.
Warning number 1: When using this plug-in in conjunction with the sequential task or sequential source control plug, be aware of the locking that is happening. A lock for the project lock name is acquired when the project integration starts. Each time a sequential task is encountered, a lock is acquired to cover the configured tasks. Each time a sequential source control is encountered, a lock is acquired to cover the source control operations.
Warning number 2: This plug in uses reflection to replace the code that runs the integration with a implementation that uses the original integration runner while holding the lock. If you are uncomfortable with this idea, please inspect the code and use at your own risk.
Instead of configuring a project in the ccnet configuration, a sequentialProject is configured. The sequential project is configured exactly like a project, and adds a lockName element as an extension.
<sequentialProject>
... all the normal project stuff ...
</sequentialProject>
<sequentialProject lockName="myLock">
... all the normal project stuff ...
</sequentialProject>
Extract the contents of the zip file. Place the files CCNet.AntPathFilter.PlugIn.dll and CCNet.Sequential.PlugIn.dll into either the ccnet server directory, or the directory where the ccnet server is started. See the Cruise Control .NET plugin documentation for details.