Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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

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.

0 votes

Comments

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
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.

1 vote

Comments

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

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 (:-).

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
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.




1 vote

Comments

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

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 log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,926

Question asked: Mar 09 '15, 5:14 a.m.

Question was seen: 4,214 times

Last updated: Mar 10 '15, 9:26 a.m.

Confirmation Cancel Confirm