1

The workspace in diagram below flows to a stream.

enter image description here

I've added a build definition which builds from this workspace. If I deliver change sets from a different workspace to the stream in diagram should these change sets be built when I perform a build ? Do the change sets need to be first accepted into the workspace from the stream before they are built ?

Currently when I perform a build the change sets(which have been delivered to the stream from a different workspace) are not being delivered to the workspace in diagram and so are not being built.

blue-sky
  • 51,962
  • 152
  • 427
  • 752

1 Answers1

1

If I deliver change sets from a different workspace to the stream in diagram should these change sets be built when I perform a build?
Do the change sets need to be first accepted into the workspace from the stream before they are built?

It depends how your build definition is configured:
As this thread mentions:

If you are using a build definition that has 'Jazz Source Control' selected as a pre-build participant, you will see in the bottom section of the 'Jazz Source Control' tab the 'Accept Options section'.
The 'Accept latest changes before loading' checkbox should be checked for you to automatically accept changes.

But with a BuildForge-based Build Definition, as mentioned in "Rational Team Concert 3.0 and Build Forge: An integration scenario":

[...] Once a Server is selected, as first Step, the Build Forge project loads an Adaptor (JazzJBE.xml) to facilitate the integration between Build Forge and RTC.
This adaptor runs the Jazz Build Engine, which is part of the buildtoolkit, to accept and fetch source code based on the properties passed on by the RTC Build Definition
(A more typical continuous integration scenario with RTC would have the Jazz Build Engine running in the background on the build Server, listening for requests. With the JazzJBE adaptor, the Jazz Build Engine is launched on demand).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • By accepting the changes into the workspace this seems to be break the security model, as changes cannot be delivered from one users workspace to another ? – blue-sky Apr 25 '12 at 16:12
  • 1
    @user470184 Sorry for the delay, I was in a train, commuting back to home. "changes cannot be delivered from one users workspace to another": correct. You can accept them (from another repo workspace, without having to go through a Stream), not deliver them (directly to another repo workspace: you need to deliver to a Stream). That is why the repo workspace dedicated to a build will automatically accept (if configured so) changes delivered by *any* repo workspace to the Stream dedicated to said build. – VonC Apr 25 '12 at 17:19
  • ah I see, thanks again. I would up vote your answers more if I could. – blue-sky Apr 25 '12 at 18:17