Here’s the scenario. A build engineer gets a request to establish a build workspace and corresponding build workspace. He creates the build workspace, gets the desired components added to it, sets the flow targets then changes ownership of the workspace to the build user’s functional ID. After that, he creates the build definition and associates it with the newly created workspace. All is good and developers can begin to use the new build definition. After a time, a request comes in to change the configuration of the build workspace, specifically the components to use. Since the build workspace is owned by the build user, any changes to it must be made by that user. Many organizations eschew the use of functional IDs or at least minimize who knows their credentials and are concerned about extra maintenance brought on by password expiration rules. What to do?
This specific scenario came up recently with a customer of mine. In particular, their build workspaces have three flow targets. The current/default is the stream with the application source and it is scoped to include a subset of the components in the stream. The other two streams are build script and configuration related. At times, the release team needs to change the components included in the scope of the application source stream. They do so currently by logging in as the build user, something they detest doing.
What they much prefer is support for team ownership of repository workspaces but that isn’t currently possible (though requested via 271760). We instead proposed a solution that put the workspace configuration change in the build script which is already performed as the build user and owner of the workspace.
As of 4.0.1, the SCM CLI includes the capability to add/change workspace flow targets. It was later refactored in 4.0.6 to the current verb-oriented form.
${scmExe} –non-interactive set flowtarget -r ${repositoryAddress} -u ${userId} -P ${password} ${team.scm.workspaceUUID} ${targetStreamUUID} –flow-components ${componentsToLoad}
Where:
- scmExe – path to scm CLI executable
- repositoryAddress – URL of CCM server
- userId – build user ID
- password – password of build user
- team.scm.workspaceUUID – build repository workspace UUID
- targetStreamUUID – stream flow target to set component scope
- componentsToLoad – space delimited list of components
Unfortunately the SCM CLI does not understand the password file format used by the Ant tasks. You either need to give it as plain text using –P shown above or login outside the build system with the option to remain logged in (on each build machine).
A simple way to get the UUID of a workspace or stream is to open it up in the Eclipse editor and select Copy URL workspace editor menu in the view header or browse to it in the Web UI to get the URL. The end portion of the URL is the UUID. For example, the UUID for the repository workspace URL shown below is _GVqXYLRpEeOdavKqgVc36Q
For components with spaces in their name, care must be taken to offset them by appropriate quotes. For my tests, single quotes worked on Linux and double on Windows.
The command will set the scope of the specified flow target (e.g. application development stream) for the specified workspace (e.g. build workspace) to include only those components in the specified list. The current configuration of the component(s) in the target stream is used.
Note if multiple flow targets exist for the workspace and a component listed is included in multiple flow targets, then scoped flows need to be used to avoid conflicts. See How should my source code be loaded from Jazz SCM?
Let’s take a look at an example. Below, the build.brm.continuous repository workspace, owned by the build user, has six components and three flow targets in its configuration. Banking Logic, Database, Java UI and Prerequisites are from the BRM Stream. Build comes from Build Scripts and Build Config comes from the stream of the same name.
The BRM Stream is scoped to only include only a subset of the components.
Assume that we wanted to add the Database component to the scope. Using SCM CLI command similar to that shown in the screenshot below, the scope can be changed to add it in.
This results in the flow target scope being changed.
Now to add this to the build script so it can be automated. Observe in the editor screenshot below that the command has been added to an exec statement in an Ant build script. 
The targetStreamUUID and componentsToLoad values need to be passed to the build script. Add these as properties of the build definitions. For example:
When the build is requested, the componentsToLoad value can be changed. In our original example, the Database component can be added in by editing the componentsToLoad build property at the time of the build request.
Should you be concerned that adding the ‘set flowtarget’ command to the build script will add unnecessary overhead, albeit very minimal, to every build execution even when component list isn’t changed, you can create a build script and definition that only performs the ‘set flowtarget’ command and run it when needed.
The example shown was for changing the flow target component scope. The technique used can be applied for other build workspace manipulations needed and supported by the SCM CLI.
Thanks to Nick Edgar, RTC Build component lead, for making me aware of the ‘set flowtarget’ command and suggesting its application to the problem described.
Tim Feeney's Blog on Jazz 