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. |
2 answers
Ralph Schoon (63.6k●3●36●46)
| 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 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.
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 (:-).
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.
|
|
Ralph Schoon (63.6k●3●36●46)
| 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 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.
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
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.
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)