Is it possible to have two almost identical build definitions for a single work space repository?

Hi Nick,

It's a good idea to let the 2nd definition trigger the 1st definition.

When reading about the requestTeamBuild, I understood the task is running on every other engines except from JBE that I am using. Is it correct? So I would have to create a second engine to trigger the 1st definition?

As you correctly assumed I have tried with two build definitions sharing the same build workspace. I get the recommendation to avoid shared build workspaces.

As for the version numbers for the builds, I think I have some problems in keeping the version numbers up to date, when I try with two definitions with their own build workspace and sandboxes. I as understand Jazz source control, every time I deliver the file storing the version numbers from the continuous build, the file should be available in the stream it was delivered to. And when the second definition at nighttime tells to accept the changes into its own build workspace and sandbox, the updated version number file, is accepted and I can use the updated file in the build.

Is that right?

Thanks for your first answer

Best regards Claus

If the first build blocks waiting for the requested build to complete, using the waitForTeamBuild Ant task, then, yes, you would need to run a 2nd JBE. But requestTeamBuild just puts the request in the queue, it doesn't wait for it to complete. So if that's all the script does, it will exit after issuing the request, freeing up the JBE to do the requested (or some other) build.

Regarding version numbers, I'm not sure what you mean by the version number file. This is not a concept from Jazz SCM, so I assume it's something specific to your build. But, in general, the SCM phase of a build does an accept into the build workspace from its target stream(s) then loads that workspace. Whether sharing the build workspace with another build definition or not, it should get the latest from the target stream(s).

The risk with having multiple definitions share the same build workspace is that there could be race conditions between the accepts and fetches of one build and another. JBE is smart enough to detect that and fail the build, rather than loading some mix of two accepts and continuing blindly. It also confuses the change history, e.g. the list of work items associated with builds for build def A may appear to be missing some, if their changes got accepted into a build for build def B. Work items are associated with a build when their associated change sets are accepted into the build workspace, which normally would happen at most once.

Thank you for your answer Nick.

 Thanks Nick, that's what I thought. Whether or not I use a separate build def for the nightly, in  the end, remains to be seen, but good to know that at the very least, I can compare snapshots and be able to look at diffs/changes as they traverse the two builds, which is what I am concerned with, mostly.

The simplest way to distinguish builds is to set a buildLabelPrefix property in the definitions, with value "N" for nightly builds and value "C" for continuous builds, so instead of just the timestamp like "20130828-1933" the build label will be "N20130828-1933" or "C20130828-1933".

 > The simplest way to distinguish builds is to set a buildLabelPrefix property in the definitions

Currently you would need separate build definitions for their email notifications to be processed differently.  That would also allow different label prefixes, and different schedules.