It's all about the answers!

Ask a question

RTC java API to inspect , accept and fetch the changesets selectively.


Krishnakumar Gurumurthy (867) | asked Mar 09 '15, 5:14 a.m.
We wanted to extend the RTC functionality of selectively accepting and fetching the change sets. Please provide leads on to the available Java API which we can leverage.

Requiredment:

Outstanding change set - changeset A, changeset B, changeset C
Build Jobs - Based on the content of the change set , it has to accept those change sets which pass the constraint. Say - Build Job A has to accept changeset A and B. Build Job B has to accept change set C.


Comments
Evan Hughes commented Mar 09 '15, 2:03 p.m. | edited Mar 09 '15, 2:04 p.m.
JAZZ DEVELOPER

Ralph's right. RTC SCM's streams are the preferred way of building a configuration. (A configuration is what we term a file tree that has a source control history)


It is possible to walk change sets to try to build a history, but that gets difficult in the presence of merges and ambiguous end states. 

Is there a reason not to use streams?

2 answers



permanent link
Ralph Schoon (61.4k33643) | answered Mar 09 '15, 8:26 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Mar 09 '15, 8:27 a.m.
If you want to do this kind of automation, you are on your own.

I could imagine you could use the RTC SCM commandline for this.
If you want to use Java, I can only suggest to start here:

https://rsjazz.wordpress.com/2013/10/15/extracting-an-archive-into-jazz-scm-using-the-plain-java-client-libraries/
and here http://thescmlounge.blogspot.de/2013/08/getting-your-stuff-using-rtc-sdk-to-zip.html
There is a lot more code on the blogs and you could search fr hints using a search engine or the search capabilities on the blogs.

Comments
Krishnakumar Gurumurthy commented Mar 09 '15, 10:27 p.m.

We have all our components (multiple components) in single stream. Depending on the changes delivered to respective, we want to invoke the respective component build. Is this achievable without any extension ? If so, I would be happy use that. So far, I did not find any mechanisms to do this.

Krishna


Geoffrey Clemm commented Mar 09 '15, 10:37 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

One approach that comes to mind is to create a separate build definition, one for each component.   Scope a build to just flow with the component to be built, and set "build only if changes".   I haven't tried this myself, but it seems like it should work (:-).


Krishnakumar Gurumurthy commented Mar 10 '15, 9:26 a.m.

Yes, I agree. Our pressing issue is all component builds gets triggered irrespective of the changes delivered to the components. As part of SCM polling, if it detects changes in component A, build corresponding to component B gets triggered. The property "Components to exclude" excludes components from loading into sandbox. We don't have any property which excludes components from accepting.

Here, the setup is - Stream -> Workspace -> Sandbox
Stream -> Workspace - team accept
Workspace -> Sandbox - team fetch (or loading). The property mentioned above applies here.

Thanks,
Krishna


permanent link
Ralph Schoon (61.4k33643) | answered Mar 10 '15, 3:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If you want to spend money on extensions, please have a look at https://rsjazz.wordpress.com/2013/02/28/setting-up-rational-team-concert-for-api-development/ and the  Rational Team Concert Extensions Workshop. You would have to create a follow up action on delivery that requests a build. You can find most of the information needed for this here:
Restrict Delivery of Changesets Associated to Wrong Work Item Types Advisor and in the other linked posts.

However, I think you can get away without it. The regular mode RTC uses is to check if there are incoming change sets on a repository workspace and then builds that workspace. You can set up build definitions and build workspaces for each of your components in the stream - each set up to only look at one component.





Comments
Krishnakumar Gurumurthy commented Mar 10 '15, 3:52 a.m.

Yes, I agree. Our pressing issue is all component builds gets triggered irrespective of the changes delivered to the components. As part of SCM polling, if it detects changes in component A, build corresponding to component B gets triggered. The property "Components to exclude" excludes components from loading into sandbox. We don't have any property which excludes components from accepting.

Here, the setup is - Stream -> Workspace -> Sandbox
Stream -> Workspace - team accept
Workspace -> Sandbox - team fetch (or loading). The property mentioned above applies here.

Thanks,
Krishna


Ralph Schoon commented Mar 10 '15, 6:40 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

My suggestion was to have an individual build repository workspace for each component that has only that component. I don't see that there would be changes to accept if you exclude the other components. I could be wrong.

Your answer


Register or to post your answer.