It's all about the answers!

Ask a question

RTC BF integrated build, JBE and team.scm.loadComponents

Martina Riedel (20323341) | asked May 03 '13, 7:35 p.m.
edited May 09 '13, 5:27 p.m. by Spencer Murata (2.3k115971)
RTC and BF
I have a stream with n components where I need to build every component separately.
The desire is to use the JBE adaptor and the Jazz Source Control (and Email Notification) tabs of the build definition. There is a separate build definition for every component and each has its own workspace.

The challenge is that the "accept latest changes" will accept all exiting components into the workspace.
Since I want only 1 component, I have to select Components to exclude, and the comment there says that it will be available as the build property team.scm.loadComponents.

This all works great if I have a small, constant number of components in the stream.

The issue is that my n is more like 20 or 30 and when the 31st (or 51st) component gets added to the stream, I would need to manually go and edit all other build defs and exclude the new component (after accepting it manually into the build workspace).

My hope was that team.scm.loadComponents would be a env var in BF, just like team.scm.fetchDestination and (most of) the others are and that I would be able to tweak it before the JBE adaptor gets called.

The issue is that It is not there.

What I really want is to just select the 1 component to load, not the 30 or 50 to exclude. That is where the Jazz Source Control selection is really really weird.

Any advice how to get what I want?

(The build only if changes accepted and the email stuff does what I want I think and if I had to re-create the JBE adaptor and all that functionality just because of the load stuff, Id be really bummed).

(The other option is to create streams with only 1 component, but that really clutters things up ....)

Spencer Murata commented May 09 '13, 5:30 p.m.

Could you add a load rule for each component to only load itself?  It would be a bit painful at first to update all the components, but then as new components are added it would just be a matter of including that load rule when you add it to source control.  Or did I miss a requirement?


Martina Riedel commented May 09 '13, 7:57 p.m.

I'd still have to go back and update all existing build defs AND create the load rules  file and do that after the new component is accepted into the build workspace. It's actually easier to just exclude it.

The other thing that is more annoying than a true blocker is that it will accept changes for all components and the "build only if changes are accepted" will start the build if changes were accepted for one of the excluded components and then be listed in the "wi included in this build". 
What really is needed is a "load named components" and the accept won't flow the  components that aren't in the build workspace to begin with.
A "build all" should still flow new components. 

Like i already said, I am trying very hard to make things work with JBE since I need to use email rules and implementing those from scratch in a BF job will be very, very hard.

Accepted answer

permanent link
Heather Fraser-Dube (4512) | answered May 10 '13, 9:50 a.m.
Try using scoped flows on your build workspace. 

If you open your build workspace definition, you will see that it has a Flow target of your stream. Select the flow target and click Edit. From there you can choose to flow only specific components. If you choose just the component that you want in the build workspace, then that will be the only one that gets into your build workspace (and subsequently loaded). It does mean though that the build will be triggered only when there are changes in that component (not when the other components change).
Martina Riedel selected this answer as the correct answer

Martina Riedel commented May 10 '13, 2:09 p.m. | edited May 10 '13, 2:09 p.m.

YAY! Such a simple thing. Now it does what I want it to do. Somehow the target flow scoping had escaped me so far.


Your answer

Register or to post 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.