More project dependencies...

[Austin Lee]

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.

thanks

[Richard Hensley]

Austin,

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
http://ccnetplugins.sourceforge.net

You basically want to replace your project element with a
sequentialProject element to indicate that only one project can build
at a time.

Richard

[SCMguy]

Thanks Richard,
I already have Project A, B, and C , but why do they need their own
"playgrounds". I understand if they need their own playgrounds for
parallel builds but since I want everything to be sequential then how
come it can't share the same playground, pls explain. but thanks for
the info...

[SCMguy]

one more question with the usage of "sequentialProject"...so if I
wanted to have the following build flow...

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>

<sequentialProject name="Project B" lockName="myLock">
...spawns off Project C after
</sequentialProject>

<sequentialProject name="Project C" lockName="myLock">
...
</sequentialProject>

[Richard Hensley]

You figured it out...

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?

[Richard Hensley]

By the way, there is a thread
http://groups-beta.google.com/group/ccnet-user/browse_thread/thread/ac850f368e676fa4/7994b89cb55df516#7994b89cb55df516
about halfway down the thread is a set of sample use case. Would
documentation of this nature been more helpful?

[Gary Feldman]

Austin Lee wrote:
>
> 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
>

Are these the only ways you expect B and C to run? That is, B will only
run as a result of A finishing successfully, and not as the result of a
source code trigger?

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.

Gary

[Moshe Hajaj]

If on the other hand, you need B to run if A is successful && its
source code changed, you can combine Richard's new plug-in with a
forcebuild trigger like this:
<forcebuild> <project>B</project></forcebuild>
assuming it's on the same server, and put it in the bottom of A's
publishers block.

-Moshe

[SCMguy]

Thanks Richard and all...
Well right now I am trying it out with the same "lock" names, and
yes better documentation would help a bit, basically explaining that
you want to use the SAME lock names for projects that are dependent on
each other and that only ONE project can run at a time with Projects
with the SAME lock names. That was the only part that I was confused
about, but I guess I was able to "infer" that was the case (but still
wasn't 100% sure until you just told me). Also one thing is when you
say that "everything within the <sequentialProject> ...
</sequentialProject> is the same as the normal <project> declarations,
is it true that if I use <projectTrigger> and <ForceBuild> (in
publisher) that I can still use the declaration <project=$project> that
was defined with the <sequentialProject> block? hopefully you were able
to understand my previous sentence ;) because I wasn't sure if since I
changed "project" to "sequentialProject" would I have to change all
other references to "project=" to "sequentialProject=". Right now I am
assuming NOTHING changes with the <sequentialProject> blocks so I kept
it as "project=". pls let me know if my assumption is right, if so this
would also be nice to document.

thanks

[Richard Hensley]

You have infered correctly, the only change is in the element names
from "project" to "sequentialProject", all the other references to a
project name stay the same.

[SCMguy]

ok thanks...its running right now...it looks good so far, but I need to
wait until more checkins occur so I can make sure Project A doesn't
auto spawn off when Project B or C is still running :) thanks again...

[Richard Hensley]

An easy way to test this is to force a build for B and then force a
build for A and make sure it all works.

[SCMguy]

So if I force a build for B and then force a build for A then your
saying that the correct behavior is that the build for A should NOT run
since build B is building? thanks...

[Richard Hensley]

Close, correct behavior is that A starts running after B is complete.

[SCMguy]

OK I found another issue...not sure if I'm misusing something or what,
but you tell me...

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
first...

Project A-> updating source tree and make clean (*starts with a checkin
detection)

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...

thanks

[Andy Johnstone]

Just want to re-iterate this...

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.

Andy

[SCMguy]

ok so if I smashed them all into ONE CCNET project then how would I
make it into 5 seperate "log" files that would seem as if they were 5
seperate one on the CCNET server, thats basically what I want to
do...yeah I could easily do that, but then there would be only ONE
Project when you go to the CCNET website to see the status of the
build, also since it won't log them until after the WHOLE project is
done, how can I see if certain parts have finished rather than waiting
for the ONE big project to finish which might take a couple of hours...

[Gary Feldman]

I thought I answered this earlier, but perhaps not.

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
for now.

Gary

[SCMguy]

ok thanks, I already figured out how to seperate the NAnt log files now
I just need to figure out the file merge task...thanks!