RTC/Jenkins integration - build only if there are source changes

There is a third option which lets RTC do the polling, and that might be more advantageous as you can send the Jazz SCM participant data to Jenkins.  Jenkins won't natively know what to do with it, but you can pipe the data to the JBE (within a Jenkins step) and have it do the source fetch and CI build determination.

Can't the RTC engine/scheduler check if there were code changes? I would assume this would be a simple check to look at the build workspace, see if there are changes to accept and launch the build. This would really improve the performance of the build system avoiding unnecessary build cycles.

I realized I was wrong about JBE function in RTC. It would still initiate a build based on the CI interval, no matter what.

Thanks
Sunil

That is exactly the check that we are using in the wiki there.  There aren't any unnecessary build cycles as we have to check at some point, and in the Wiki we are doing it from Jenkins. 

I don't understand why the polling for source code changes should happen in Jenkins while all the required objects (RTC workspace, build definition, RTC stream, CI interval, include/exclude components, the config to "build only if source changes accepted") are all in RTC.

Also, this would mean several thousand build configurations in Hudson/Jenkins in an enterprise environment trying to poll RTC for source changes. I think it would be good to get have the polling on RTC side. That makes it easier to template builds in RTC/Jenkins and developers don't have to worry about logging into build system to configure their jobs.

Thanks
Sunil

This is how most CI builds are deployed.  Users generally do not want the CLM server to be tasked with determining if a build should be run or not since that activity will not scale well to larger deployments.  Those several thousand build configurations would be processed every hour by the server greatly increasing load.  Generally it is better to task the build system with determining if the build should proceed.  

Instead of polling either from RTC side or from Jenkins side, would be good to have Jenkins listen to changes in the RTC Stream and build immediately after noticing a new change. Like SubVersion Jenkins integration.

Now that the new Jenkins plugin has been released, we recommend using that instead.  If you configure the scheduling on the Jenkins side, continuous builds should be handled as you expect: it polls the server for changes, and only runs the build if changes are found.

See https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin

and the referenced tutorial wiki page and video.