Global workingDir and artifactDir

4 views
Skip to first unread message

PilotBob

unread,
Dec 10, 2008, 2:31:28 PM12/10/08
to ccnet-user
Currently in the <project> node of the config you can specify a
workingDirectory and an artifactDirectory. You can provide a full path
or a relative path. If relative it is relative to the folder where the
server was started from. Also, several other settings in the other
config blocks can have paths relative to these folders.

However, what I want to do is know if there is a way to specify the
default parent for these folders. So, rather than having to enter the
same full path in many projects I can just define it once. I ask
because usually I just accept the default relative paths for most of
my config blocks. I don't seem to see a way to do this.

Yes, I know that I can use an XML entity or a pre-processor define to
make this a bit easier.

What would be nice is if at the cruisecontrol config level you can add
a "workingDirectory" and/or "artifactDirectory" which would then be
used as the root for all relative paths rather than the EXE folder.

Anyone have any comment on this? Or why it is a stupid idea or what I
am missing?

BOb

Sam Calder

unread,
Dec 11, 2008, 11:11:30 AM12/11/08
to ccnet-user
My $0.02...

Just thinking, If you have a bunch of parameters that will be
"constant" (or at least default) across all projects, you could
probably define them in a single XML file and then use <cb:include> to
include that one file in all your other configs... then use the
preprocessor to extract the particular params you need for that file
by name...

Caveat: I've not actually tried this, because I've never really found
a need to. In my experience ccnet has very sensible defaults and a
human-readable XML schema (one of the best things going for it,
actually!), which means the config for even a fairly major build is
still short and understandable... and even if you have to specify your
working directory as "C:\Builds\<projectName>\" in each individual
file, doing so it keeps it flexible. Plus, it means other developers
on the various project teams (who may only be vaguely aware of the
existence of a build process, let alone understand the inner workings
of CCNet) only need to look in one single file for any given project
to figure out the build process and params for that project.

Cheers,

- Sam.
Reply all
Reply to author
Forward
0 new messages