Build repository workspace retrieves all stream components

The reply above, about how accept will add any incoming components, is correct. However, you can limit that by specifying a scoped flow. Open the workspace editor on the build workspace, select the flow target (i.e. your stream), press Edit..., choose 'Flow only components checked below', and chek the components you want to include.

However, this has the disadvantage that the snapshot created from the build workspace will not include the excluded components. You might want it to do this, even if they're not included in the build, to be able to later back-track to a consistent configuration.

Recent 2.0 builds include the ability to exclude certain components from being loaded during the build. So changes/components will still be accepted, but not all components will be loaded. See the 'Components to exclude' entry in the Load Options section of the Jazz Source Control tab in the build definition editor (just before 'Component load rules').

If the build definition is set to accept all incoming changes then it will also load the other components as they will be marked as incoming additions. In our case we have 9 components and only need to load 3 for the build. I then added load rules on the other 6 to load only a specific directory (containing the load rule for the component) and no load rules for the other 3. The result is that the build engine only spends minimal time in loading the 6 components but loads everything on the 3 components required for the build.

ciao!

Thanks for reply and the explanation actually makes some sense.

We have 4 components to build 3 different build targets. All three require a base component and each of the others requires a unique component.

So I had set up the workspace for each build to select the base component & one required component since that's all I need for that particular build.

So I'm thinking that creating component rules probably won't work for me but I'll give it a try.

If I was in your position then I would use a single workspace, a single build engine and three different build definitions. Each definition will then have a different mix of load rules for the unique components.

Would that work?

ciao!

I am using a single build engine and three different build definitions. I like the idea of using a single workspace. I thought the load rules would be associated with the workspace, not the build definition. I hope to have some time next week to look at this.

Also, it's not recommended to use the same build workspace for multiple build definitions. In particular, this can cause confusion in the resulting "included in build" links, since these are calculated based on when a change set is first accepted into the build workspace, not based on a delta from the previous build for the same definition.

The reply above, about how accept will add any incoming components, is correct. However, you can limit that by specifying a scoped flow. Open the workspace editor on the build workspace, select the flow target (i.e. your stream), press Edit..., choose 'Flow only components checked below', and chek the components you want to include.

However, this has the disadvantage that the snapshot created from the build workspace will not include the excluded components. You might want it to do this, even if they're not included in the build, to be able to later back-track to a consistent configuration.

Recent 2.0 builds include the ability to exclude certain components from being loaded during the build. So changes/components will still be accepted, but not all components will be loaded. See the 'Components to exclude' entry in the Load Options section of the Jazz Source Control tab in the build definition editor (just before 'Component load rules').

This was exactly what I needed. Thanks so much for the solution.

My pleasure. Which approach did you take: using a scoped flow, or the new 'Components to exclude' feature?

My pleasure. Which approach did you take: using a scoped flow, or the new 'Components to exclude' feature?

We're still using RTC 1.0.1.1 so the new feature is not available to us. I also don't think that the snapshot limitation is a concern for us. We would only need the desired components in the stream to recreate the environment so the fact that's all the snapshot grabs seems okay. So scoped flow is perfect. And much easier than figuring out the component load rules. I fixed four projects in less than 10 minutes :-)

I did make a note in my resolution comments, though, about the RTC 2.0 feature, so we might make use of it after we upgrade.

Good to know, thanks for clarifying.