Going forward I'm looking to have a better sequence of builds in Jenkins. This is difficult when the whole stack can take more than 16hrs to build, so having SVN checks every 6 hrs (as we do today) might not be ideal if there's a ton of upstream changes coming down the pipe. If you spread the 25 components out in approximate order, assuming that no two run in parallel (which is of course not the case but makes it easier to estimate times) then a fresh CDI build is over 9 hours after a fresh usage, tests, or common build. Since CDI has over an hour of tests in it, Seam is therefore close to 12 hours down the stack. Thus if a change comes in to Common at 00:00, Seam might start building at 12:00. If a change comes in to Common at 9:30 while Seam is spinning, it won't spin again for another 12 hours, during which time CDI might respin. Now, if there were API changes in Common which affected both CDI and Seam, only CDI will have seen the change (as Seam will still be pending) and we could end up with a mismatch in the JBT aggregate. Or, as is often the case you describe, you see the change in SVN, respond to it, and have a fix in SVN HOURS before a build appears that picks up the change. In between, you might get a compilation error email complaining about the older version of the source. One thing I was prototyping (only implemented partially) for the JBDS 5 builds was to use the Parameterized Build Trigger plugin instead of the default Build Trigger plugin; this new one allows the same SVN revision used upstream (eg., by Common) to be used downstream (eg., by Seam) so that in theory the source versions would be compatible. On further reflection, it occurs to me that this too could cause problems because if a change is needed in Seam to react to a change in Common, then the version of source used by Seam would be GREATER than the version of the source used by Common; forcing them to be the same would mean we'd be building against old sources. This would be another reason why we'd get Jenkins emails complaining about test failures or compiler errors which would not be seen when building/testing locally w/ Tycho. On 08/30/2012 01:51 PM, Alexey Kazakov wrote: -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

Not sure... you tell me: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-3.3_stabl... (3.3.x branch) https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-3.3_trunk... (trunk) On 08/30/2012 03:02 PM, Alexey Kazakov wrote: -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

have this change been done on our jenkins instance ? /max On 30 Aug 2012, at 23:28, Denis Golovin <dgolovin(a)exadel.com&gt; wrote:

On 08/30/2012 07:51 PM, Alexey Kazakov wrote: So you mean that Jenkins jobs are not useful for you? If there are problems with builds/environment, then please open Jiras to explain what are those problems and how to solve them. Jenkins is meant to be helpful for you. I don't think that it's a good idea to rely on build or QE team to provide feedback on your component build, we can't spend all our time to look at status of Jenkins job and warn X or Y about an issue in a build. It should be the reverse process: component developer look at there CI job, and when they see an error is caused by Jenkins environment, they push it up to build through a Jira. Or if not exclusively, it should be both process: Nick/Denis/I monitor Jenkins to see whether there are some issues, and at the same time the component team look at their jobs to see whether there are some issues. We'll probably reduce the feedback loop that way. I understand that Jenkins has a long time-to-feedback currently. That's something that is currently discussed to get way shorter feedback, so it will be more helpful. Doing local build is a very good habit, and is often more performant than waiting for CI feedback. But ignoring feedback for CI is just like ignoring a colleague who says "I can't build", there is a reason, which may be caused by anyone, and it's necessary to determine what is the reason and how to solve it. We are working and make it "faster" and better isolation between components will make it more stable. But I can understand how current problems led you to ignore Jenkins mails, that's what we need to fix ;) -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>