Specifying a dynamic "Load Directory" for a build?

It's not possible to do this.

One workaround might be to move the loaded directory. I'm not sure this
would work in all cases, but might be worth experimenting with. It worked
for my simple test case.

Make sure the Load Directory in the Jazz SCM page in the build definition is
NOT blank. Specify something like "fetched".

The following example assumes the build file is in project foo, and once
fetched, the structure looks like:

fetched/foo/build.xml

Then, in your build.xml, do something like this:

<target name="moveFetched">
<!-- make a peer directory of "fetched" named with the build label -->
<mkdir dir="${basedir}/../../${buildLabel}"/>

<!-- move the fetched directory into the peer -->
<move file="${basedir}/.." todir="${basedir}/../../${buildLabel}"/>
</target>

This will basically move the "fetched" directory into a directory named with
the build label. You end up with:

20080308-1234/fetched/foo

Be careful with the moving because you could end up moving the wrong thing
and messing up the build engine directory. You might want to make a backup
of /jazz/buildsystem before you start experimenting :-)

---
Ryan Manwiller
Jazz Team Build

Interesting idea.

Does the design of the BuildEngine assume that anything 'publishable' or
permanent should be published to the server ?

Nevertheless, do you think that supporting ${buildLabel} within the
build definition is a plausible enhancement ?

I could certainly use a feature like that

Regards

Ryan Manwiller wrote:

It's not possible to do this.

One workaround might be to move the loaded directory. I'm not sure this
would work in all cases, but might be worth experimenting with. It
worked for my simple test case.

Make sure the Load Directory in the Jazz SCM page in the build
definition is NOT blank. Specify something like "fetched".

The following example assumes the build file is in project foo, and once
fetched, the structure looks like:

fetched/foo/build.xml

Then, in your build.xml, do something like this:

target name="moveFetched"
!-- make a peer directory of "fetched" named with the build label --
mkdir dir="${basedir}/../../${buildLabel}"/

!-- move the fetched directory into the peer --
move file="${basedir}/.." todir="${basedir}/../../${buildLabel}"/
/target

This will basically move the "fetched" directory into a directory named
with the build label. You end up with:

20080308-1234/fetched/foo

Be careful with the moving because you could end up moving the wrong
thing and messing up the build engine directory. You might want to make
a backup of /jazz/buildsystem before you start experimenting :-)

---
Ryan Manwiller
Jazz Team Build

Does the design of the BuildEngine assume that anything 'publishable' or
permanent should be published to the server ?

I don't quite understand your question. The design of the build engine
doesn't really assume anything about publishing. The build engine is just a
loop that spawns a process to run ant or the command of your choosing. The
output of this command is published as the Full Build Log. The engine does
allow plugins. There are a few plugins for it that publish information
about workspace, work items, etc. Regarding built artifacts, it up to you to
manage them how you'd like. I'm not sure if I answered your question. If
not, can you be more specific?

Nevertheless, do you think that supporting ${buildLabel} within the build
definition is a plausible enhancement ?

Supporting variables in the build definition would be very nice and its a
reasonable enhancement to file. However, I don't think this will happen for
1.0.


---
Ryan Manwiller
Jazz Team Build

In particular, for the Jazz team's own use of the BuildEngine, the only
things that are publish'ed back to the server are progress information
and references (i.e., references back to files on the build server, such
as downloads, logs, etc.). So for example, references to the available
downloads are published to the server, but when you click on one of
those references, you are causing a download directly from the build
machine to your machine.

Cheers,
Geoff

Ryan Manwiller wrote:

Does the design of the BuildEngine assume that anything 'publishable'
or permanent should be published to the server ?

I don't quite understand your question. The design of the build engine
doesn't really assume anything about publishing. The build engine is
just a loop that spawns a process to run ant or the command of your
choosing. The output of this command is published as the Full Build Log.
The engine does allow plugins. There are a few plugins for it that
publish information about workspace, work items, etc. Regarding built
artifacts, it up to you to manage them how you'd like. I'm not sure if I
answered your question. If not, can you be more specific?


Nevertheless, do you think that supporting ${buildLabel} within the
build definition is a plausible enhancement ?

Supporting variables in the build definition would be very nice and its
a reasonable enhancement to file. However, I don't think this will
happen for 1.0.


---
Ryan Manwiller
Jazz Team Build

That's not totally true...we only create an external link for the artifacts that make up the build because of their large size. Everything else of substance(logs, JUnit results, etc.) are all published as items and/or content in the repository.

Don Weinand
Jazz Team Build

See https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/19206
and https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/41476 before filing a new request. I think one of these work items covers what you are asking for.

Martha
Jazz Team Build Component