[jbosstools-dev] Please take care of CI job for your component!

[Nick Boldt]

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:
> To be honest, I ignore Jenkins emails. My experience shows me that 95%
> of these problems are problems of hudson build(s)/environment/... or
> problems which I'm already aware of.
> Instead of rely on the hudson builds I regularly run tycho build
> locally. It safes our time. So instead of investigating what is going on
> with hudson builds every time I got Jenkis email we (CDI/Seam/JSF team)
> can spend time on development running local tycho build every other day
> to make sure everything is ok on our side.
> We mentioned these problems in JIRA and in emails but the hudson builds
> is still unstable.
>
> On 08/29/2012 11:58 PM, Mickael Istria wrote:
>> Hi all,
>>
>> This is a warning since we plan a code freeze for tomorrow: a lot of
>> jobs are failing (timeout, or just compilation or assembling issue, or
>> Jenkins configuration). As developers on a component, you must react
>> to a build becoming red, so don't ignore Jenkins mail notifications,
>> read the log when a build fails and*fix it ASAP*, if you can. You may
>> be interested in receiving mails specifically for your component, so
>> you can add you mail address on the Configuration page, "Mail
>> notifications" section.
>> In some cases, log is explicit and shows what file crashed the build.
>> So you can guess what you need to do to fix it.
>> In other cases, it is be an environment issue, then open a ticket to
>> the Build/Releng component and assign it to Nick or I depending on
>> your timezone, so we can help to get the job back to work.
>>
>> Since we are moving to bigger components, with more isolation, you
>> really need to be careful about the status of your component CI job.
>> Please don't wait for QE or Build crew to discover issues and fix it,
>> it simply won't scale.
>>
>> Cheers,
>> --
>> 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>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com