Question

I am setting up a nightly build using ccnet 1.6 to run projects sequentially and exclusively, but however I set up the queues when the build is triggered the projects do not start in the expected order as defined by the queue priority. The config below randomly starts queues 1, 2, 3 or 4 first then completes the remaining projects in the defined sequence order (ie 2, 1, 3, 4 or 3, 1, 2, 4 etc). I’ve tried xlmns 1.6 and 1.5 with same results. I can’t see why this is not working, am I missing something?
Thanks

 <cb:define name="Common">
  <webURL>http://hostname/ccnet/server/local/project\$(CCProjectName)\ViewLatestBuildReport.aspx</webURL>
  <workingDirectory>D:\source\$(ProjectName)</workingDirectory>
  <sourcecontrol type="svn"/>
  <modificationDelaySeconds>60</modificationDelaySeconds>   
  <triggers>
    <scheduleTrigger time="11:05" buildCondition="ForceBuild "/>
  </triggers>
  <state type="state" directory="C:\Program Files\CruiseControl.NET\server" />
</cb:define>

<cb:define name="BuildProject">
  <project name="$(CCProjectName)" queue="SequentialQueue" queuePriority="$(QueuePriority)">
    <cb:Common />
    <tasks>
      <exec>
        <executable>$(ANT_HOME)\bin\ant.bat</executable>
        <buildArgs>-logger org.apache.tools.ant.XmlLogger -logfile build_log.xml -f build\$(ProjectName).xml</buildArgs>
      </exec>
    </tasks>
    <publishers>
      <merge>
        <files>
          <file>D:\source\$(ProjectName)\build\*.xml</file>
        </files>
      </merge>
      <xmllogger /> 
    </publishers>
  </project>
</cb:define>    

<cb:BuildProject CCProjectName="API" ProjectName="api" QueuePriority="1" />

<cb:BuildProject CCProjectName="Ack" ProjectName="acknowledgement" QueuePriority="2" />

<cb:BuildProject CCProjectName="Error" ProjectName="error" QueuePriority="3" />

<cb:BuildProject CCProjectName="Monitoring" ProjectName="monitoring"  QueuePriority="4" />

Answer 1

I’m guessing this is a bug in CruiseControl.Net, your scenario (variable priority projects in one queue triggered by the same schedule trigger) is not a common one. You should file a bug on cruisecontrolnet.org.

A more usual solution for this kind of setup is having the projects trigger each other using <projectTrigger/>, which also results in a sequential build. You’ll probably want to change the triggerStatus parameter so that a failed build does not stop the chain.