Choosing which components to load during an RTC build
I'm trying to setup a test build to run my predefined test suites in ANT. I've got a repository workspace configured with just the "TEST" component.
I'm trying to control the way that RTC accepts incoming changes during the source control phase. I want to avoid loading the "SOURCE" component and only load "TEST"
It appears that after a build runs, "SOURCE" appears in my workspace definition, and is loaded in the working dir of the build. This adds about 20 minutes to the overall turnaround of my tests.
I've tried removing the component from the repository workspace, but they continue to get reloaded during builds. So far the only solution I've found is to disable auto acceptance of changes and manually accept changes prior to running the test build manually.
Ultimately, I would like to have this automatically configured so that I can schedule the test build. Can this be done? Do I need a separate stream?
I'm trying to control the way that RTC accepts incoming changes during the source control phase. I want to avoid loading the "SOURCE" component and only load "TEST"
It appears that after a build runs, "SOURCE" appears in my workspace definition, and is loaded in the working dir of the build. This adds about 20 minutes to the overall turnaround of my tests.
I've tried removing the component from the repository workspace, but they continue to get reloaded during builds. So far the only solution I've found is to disable auto acceptance of changes and manually accept changes prior to running the test build manually.
Ultimately, I would like to have this automatically configured so that I can schedule the test build. Can this be done? Do I need a separate stream?
4 answers
RTC will accept all incoming changes to a workspace if that flag is set in the definition. If you want to limit the files being loaded in the local repository then you would need to use load rules.
The online help version is here: https://jazz.net/help/rational-team-concert/1.0.1/topic/com.ibm.team.build.doc/topics/r_scm_build_loadrules.html
ciao!
The online help version is here: https://jazz.net/help/rational-team-concert/1.0.1/topic/com.ibm.team.build.doc/topics/r_scm_build_loadrules.html
ciao!
Are you using RTC 1.0 or 2.0? If 2.0, you can exclude selected component in the Source Control tab of the build definition.
In 1.0 (and 2.0), you could also use a scoped flow:
- open the workspace editor for the build workspace
- select the stream in the Flow Targets section
- click Edit...
- choose 'Flow only components checked below' and check the components you want to include
One caveat with this approach is that if you define a new component, you need to remember to update the build workspace's scoped flow to include it.
In 1.0 (and 2.0), you could also use a scoped flow:
- open the workspace editor for the build workspace
- select the stream in the Flow Targets section
- click Edit...
- choose 'Flow only components checked below' and check the components you want to include
One caveat with this approach is that if you define a new component, you need to remember to update the build workspace's scoped flow to include it.
To close the loop on this, my server upgraded to RTC 2.0 and now I have a handy dropdown to choose which components from the workspace to load at runtime, so that was exactly what I needed.
I couldn't have used load rules since they are scoped only within a component.
I still do find it odd that when I add a component into my workspace from a different stream, it immediately disappears when the build runs. I have worked around this by using the teamFetch target to bring in components from other workspaces (workspaces flowing with different streams)
I couldn't have used load rules since they are scoped only within a component.
I still do find it odd that when I add a component into my workspace from a different stream, it immediately disappears when the build runs. I have worked around this by using the teamFetch target to bring in components from other workspaces (workspaces flowing with different streams)
Thanks for closing the loop. The build workspace is brought into sync with the contents of its flow target(s), so if it has a component not in the flow target, it will be removed. Normally this is desired behaviour, e.g. if you remove a component from the stream.
Note, however, that the build workspace may have multiple flow targets, in which case it will accept changes from all of them. If there's overlap between them, you should configure scoped flows to avoid collisions.
Note, however, that the build workspace may have multiple flow targets, in which case it will accept changes from all of them. If there's overlap between them, you should configure scoped flows to avoid collisions.