It's all about the answers!

Ask a question

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


SUNIL KUURAM (6431923) | asked Feb 07 '13, 7:39 p.m.
edited Feb 27 '13, 11:56 a.m. by Spencer Murata (2.3k115971)
 Hello Everyone,

I am trying to use RTC/Jenkins integration in RTC 4.0. Having setup a Jenkins engine, I am setting up a build definition with Jazz Source Control enabled. I have "Build only if changed accepted" checked and scheduled a build to run every 5 minutes. At this time, I would expect the build scheduler to look for changes and submit the build into Jenkins only if necessary. However the build definition triggers builds no matter what.

I have seen the expected behavior in RTC 3.0 with JBE. With Jazz Source Control enabled, you won't even see a build triggered unless there are source changes, avoids unnecessary cycles/build requests at the JBE.

This is a very useful feature, not sure why its dropped in Jenkins integration. Any ideas?

Thanks
Sunil

Comments
Bernie Bonn commented Feb 27 '13, 11:02 a.m. | edited Aug 18 '15, 5:37 p.m.

Hi Sunil,

Had any luck with this?  I am trying to do the same thing.

Thanks !
Bernie

4 answers



permanent link
Arun K Sriramaiah (3.2k13177) | answered Aug 19 '15, 1:17 p.m.
HI Sunil,

In Addition to Spencer\Nick's answers, Please find the blog for same requirements and let us know does it helps.

Scheduled Jenkin Build Should run only if there are "changes accepted "

https://www.ibm.com/developerworks/community/blogs/nfrsblog/entry/scheduled_jenkin_build_should_run_only_if_there_are_changes_accepted?lang=en

Regards,
Arun.

permanent link
Nick Edgar (6.5k711) | answered Jul 18 '13, 11:01 a.m.
JAZZ DEVELOPER
As Sam stated above, the RTC/Jenkins integration that runs server-side doesn't know about SCM.  Nor does our scheduler know about SCM (that would be a major design change).  You need something in the Jenkins build to run the SCM phase, either via a Jenkins plugin or using a script calling out to our Ant tasks and/or JBE.  The latter was the approach recommended in the above-mentioned wiki page.

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.

and the referenced tutorial wiki page and video.


Comments
Chidambaram L commented Feb 21 '19, 11:54 a.m. | edited Feb 24 '19, 7:09 p.m.

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.


Davyd Norris commented Feb 21 '19, 5:51 p.m.
See above - that's what it now does in the official Jenkins plugin
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.

and the referenced tutorial wiki page and video.


permanent link
sam detweiler (12.5k6195201) | answered Mar 17 '13, 11:08 p.m.
edited Jul 18 '13, 11:39 a.m.
the current rtc/jenkins integration is only at the Job/Build definition level. there is no Source smarts.

so, you either have to manually initiate a job, or the jenkins server has to poll.  in either case you may in fact not need to build. for Source code activities, you have a few choices.. use JBE or some ANT tasks to talk to RTC SCM, or the open source RTC jenkins plugin, which altho primitive is easy to use. but it loads the whole workspace every time.

IBM says they are working on some triggering mechanisms, but not in 4.0.2 just released.

Comments
Spencer Murata commented Mar 18 '13, 8:36 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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.


We are working on an 'official' Jenkins plugin that will give the same functionality that Jenkins has with CVS, SVN, etc.

~Spencer


permanent link
Spencer Murata (2.3k115971) | answered Feb 27 '13, 11:56 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
 You will still need to call the JBE from the Hudson build to use the Jazz SCM participant.  The participant is just a bunch of data that the JBE happens to know how to interpret, however Hudson by itself does not know what to do with it.

There is an indepth article on this on the wiki:
https://jazz.net/wiki/bin/view/Main/JazzScmWithJenkins

~Spencer

Comments
SUNIL KUURAM commented Mar 17 '13, 2:55 p.m. | edited Aug 18 '15, 7:47 p.m.

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


Spencer Murata commented Mar 18 '13, 8:32 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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. 


SUNIL KUURAM commented Mar 18 '13, 11:05 a.m.

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


Spencer Murata commented Mar 18 '13, 2:29 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

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.  


The developers will have to log into Jenkins regardless to configure their jobs.  You could provide an Ant script as a library to handle the CI polling since it will be the same for all users, just with different parameters (stream, user, etc.) 

~Spencer

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.