Hello...I figured out how to use "Force publish build" and "Porject triggers" (with CC version 1.1.1), BUT I am running into an issue for a build...here's the scenario
Project A: will "update the code" and do a "make clean" upon checkin of a certain area in subversion (or any source control system)
Project B: will kick off once Project A is SUCCESSFUL (using project trigger) say its doing a "make -debug" or something
Project C: will kick off once Project B is done via a "Force build publsher" in Project's B declaration and say its doing a "make -optimize" or something in the same tree
So the problem is there is no "wait" type mechanism or anything (that I know of) so say someone checks in and Project A kicks off, then Project B kicks off after Project A is successful...and onto Project C...
So say when its on Project C someone checks in code and then Project A starts AGAIN while Project C is still building, and Project A does a "update and clean" of the code, clearly stepping on Project C's feet...
Is there anyway to get this to work within Cruisecontrol, I am using Nant along with it.
You can handle this in one of two ways.
One, Project A, B, and C must have their own play grounds. This is
documented in the ccnet documentation under multiple projects.
Two, you can use some plug ins I created to ensure that the projects do
not build in parallel.
You can find information abou the plugins at
You basically want to replace your project element with a
sequentialProject element to indicate that only one project can build
at a time.
Project A-->Project B-->Project C (BUT I didn't want Project A to run
as long as B or C is running) would I set it up something like
below...I tried reading the documentation but I wasn't sure how its
using the "lock name" so the 3 projects share the same lock name does
that make them dependent on each other? is that the rule of thumb? or
am I misunderstanding something...
<sequentialProject name="Project A" lockName="myLock">
...spawns off Project B after
<sequentialProject name="Project B" lockName="myLock">
...spawns off Project C after
<sequentialProject name="Project C" lockName="myLock">
I'm working on the documentation right now based on feedback like this.
Basically, projects wait for a lock with the specified name to be
available before starting. So, if all your projects have the same lock
name, only one will start at a time.
Do you have any suggestions about a better way to document this?
If that's the case, then just merge them into one project. There's no
need to set up complicated dependencies. If you want earlier
notification, put in additional email publishers or use NAnt to send
email. If you want the results on the dashboard to be separate, then
collect the output files separately and use separate projects whose sole
action is to merge the previously generated output files into their
CC.Net result stream.
Here's my "real world" scenario...I have 5 projects, all that have to
be done in the SAME playground. So I implemted the "sequentialProject"
and at least now it will ONLY run one project at a time which is good
(all projects have the SAME lockName), BUT...read the below scenario
Project A-> updating source tree and make clean (*starts with a checkin
Project B-> building with flavor B (uses project trigger to start if
Project A is successful)
Project C-> building with flavor C (is called by "forceBuild in
publisher" by Project B)
Project D-> building with flavor D (is called by "forceBuild in
publisher" by Project C)
Project E-> building with flavor E (is called by "forceBuild in
publisher" by Project D)
BUT (continued)...say its building Project C which at the end is
suppose to FORCE the build to go to Project D, BUT if there is a
checkin during this time Project A will detect it and for some reason
it will JUMP back to Project A instead of going to Project D via the
"force build publisher"...any idea how to get around this? or if this
is even the correct usage of the sequentialProject plugin? Any help
will be appreciated...
This is exactly why your projects should either 1) not share the same work
area or 2) your projects should be rolled into on CCNET project.
Separate out your various log files. For tasks such as MSBuild, this
means providing an explicit log file name so that you can get at it
(instead of CC.Net's implicit inclusion). At the end of each phase, add
a step that copies or moves the file(s) to a fixed location. Set up
separate CC.Net projects to monitor those fixed locations (using a file
trigger, or possibly a ForceBuild publisher task in the main build).
When they're triggered, they should merge the files into their own
output, which will make them available via the dashboard. Then delete,
move, or rename them so that they don't get included the next time.
So suppose phase A runs a NAnt script to produce phaseA.log.xml. When
it's done, you use a separate NAnt script to move it to
handoff/phaseA/phaseA.buildNumber.log.xml (adding in the build number).
Project AReporter gets triggered, moves it to
inprogress/phaseA/phaseA.buildNumber.log.xml, uses a merge task with
wild cards to get it into its CC.Net log, and then moves it to
done/phaseA/phaseA.buildNumber.log.xml. When it finishes, any email
goes out and the logs are available in the dashboard. I'm using
separate directories here, but you could use a file name convention instead.
This won't get you output from things built into CC.Net that don't
produce separate log files (like the source control update), but usually
they're uninteresting unless something goes wrong - in which case, the
great big MasterBuildProject will fail at that point, and you'll be able
to see the output there.
This approach is a kludge, but I think it can satisfy your requirements