Personal builds in Team Concert + Build Forge
I suspect I've overlooked an obvious manual, but I'm having a local
problem browsing the jazz.net library at the moment. So if you have a suggestion about TFM that I should R, please point it out to me. Or, given that this question is about RTC as well as Build Forge, perhaps another forum is better? I've seen <http>, "Using the SCM Command Line Interface in builds", by Evan Hughes, RTC Source Control Team. I'm most interested in Recipe 1: Delivering Generated Resources Back to the Parent Stream. The general shape of the solution is simple: an Ant macrodef that calls exec on scm checkin and scm deliver. But there are a couple of gotchas: 1. We should only deliver the change set that contains the build artifact we built. A blanket deliver could flow more changes than the one we want to push. 2. The artifacts generated by personal builds should not flow to the stream. ... Preventing personal builds from flowing to the stream is a harder nut to crack, as it requires some Ant-fu. The Ant target __scm-checkin should only be executed if we're running outside of a personal build. The Jazz build engine flags personal builds with the property ${personalBuild}, which is available in the generated build.properties file. "Personal builds" links to <http>, which explains a little bit about the RTC Personal Builds feature. There are several references to the "autogenerated" build.properties file, but I don't see a link that explains what's in the file, how it is generated, where it is generated, et cetera. Does someone have a URL? -- Tim McDaniel, tmcd@panix.com |
3 answers
I'll see if I can find information or someone that understands what's going on with the SCM command line utility wrt your question. However, just wanted to point out that the RTC/BF integration in RTC 3.0 has some enhancements that includes support for Personal Builds when using JazzSCM. Here's a link to the description.
http://jazz.net/forums/viewtopic.php?t=10252 I'll see what I can find out about the build.properties question you asked. Regards, Pete |
In the context of the CLI article, build.properties is a file containing all the build properties, and is configured in the 'Properties file' field of the build definition (optional).
If the build definition launches your Ant script directly, then all the same properties are already passed to Ant via its -propertyfile command line arg (whether you set the Properties file field or not), so that part of the setup in the CLI article and the:
snippet in the script are not really necessary. Making a target conditional on a personal or non-personal build should be as easy as declaring: <someTarget if="personalBuild"> ... or <someTarget unless="personalBuild"> ... The CLI article actually uses this approach. For more details, see http://ant.apache.org/manual/targets.html Regards, Nick |
|
In article <ht3nl5>,
nedgar <Nick_Edgar> wrote: In the context of the CLI article, build.properties is a file At our site, Team Concert is integrated with Build Forge; when I start a build in RTC, it starts its associated project in RBF. So when the documentation talks about the "build.properties file", I assume that I should just read it as "the environment with which the RBF project starts". -- Tim McDaniel, tmcd@panix.com |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.