chtbuild wrote:

How can I control exactly what goes into a build. I need to be able
to set up a build that has a previous snapshot as its base, and then
add one or more work items on top of that, and not just all available
work items.

Why do you need to do that? What problem are you trying to solve?

I don't think it is easy to do what you want, so it may help to take a
step back to find a different way to solve the real problem.

(By the way, it's polite to use a real account, not a functional ID, to
post messages to a forum.)

How can I control exactly what goes into a build. I need to be able
to set up a build that has a previous snapshot as its base, and then
add one or more work items on top of that, and not just all available
work items. From the Jazz doc it sounds like I should create a Build

You can create a new workspace based on the snapshot, set the desired
flow target and accept the required work items from a stream /
workspace. As long as there are no conflicts to resolve, you do not even
need to load the workspace (Select the "Do not load anything. The
workspace will be tracked by the pending changes view").

Then simply request a build, open the "Build Options" in the dialog,
check "Personal Build" and select the newly created workspace.

Assuming I can accomplish item 1 above, it seems that I would use the
teamFetch target to grab all the source that was just defined. Then
I can do my compiles, etc. If the build is successful, I need to be
able to promote the work items I just used into the main stream and
save it all as a snapshot of a good source grouping that can be
rebuilt, if ever needed, and also be used as a base for the next
build I do. If the build failed, I need to be able to discard that
snapshot since it is no longer needed.

Deliver the changesets to the main stream and create a new baseline. By
doing this, the configuration is tagged and can always be rebuilt.

I use personal builds before flowing changesets from/to our team's
stream to/from the integration stream in order to verify everything
compiles and the tests are green. Another use case is to create a build
containing a patch.

--
MikeS
Jazz Agile Planning team

chtbuild wrote:

I'm not really trying to solve a problem, per se. I'm trying to
modify my existing build automation, which currently makes use of
CMVC as the source code repository, so that it can interface with a
JAZZ source code repository.

In other words, the problem you are trying to solve is to have your Jazz
build system behave just like your CMVC build system. Don't do that.
The way that work flows through the system is different in CMVC and
Jazz, so the build systems will have to be different.

It sounds like your current system is designed to test changes in a real
build before committing them to the official product build. My best
suggestion for how to do something similar in Jazz is as follows: Have
the build system take an input parameter of the Jazz repository
workspace to build from. The build tool would fetch that workspace and
build from it, but would not accept any changes into that workspace,
deliver any changes to any stream, or create any baselines. When
developers are ready to deliver a change to the integration stream, they
would ask the build system to build their personal workspace. If the
build passes, the developer is then free to deliver his change. If the
build fails, the developer has more work to do before delivering.

My team does something like that. Developers aren't required to run a
test build before delivering, but most non-trivial changes are run
through a test build first. We find that the system works quite well.
(Though I have never used CMVC, so I can't compare it to what you have.)

I could imagine a system that is more automated. Developers would
deliver their changes to a trial integration stream. The build system
would always accept changes from that trial integration stream, create a
baseline, and run a build. If the build passes, the baseline would then
be automatically delivered to the real integration stream. I don't know
if you could get as fined grain control over change sets as you have
with CMVC. I don't know how much work it would be to set this up.