[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-10437: ------------------------------------ upstream-downstream plugin now enabled for these views: https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/po... (currently 3.3.0.Beta1) https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_3.3.indi... (currently 3.3.0.M5) https://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Stable_B... (3.2.x) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-10437 at 2/6/12 11:57 AM: ------------------------------------------------------------- Further suggestion from Max/Doug: to allow loose coupling/watching by SOA Tooling jobs of upstream Core jobs, we might be able to use the URLTrigger plugin to watch MD5 hashes of update site zips or upstream jobs themselves, eg. http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_trunk.... or https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/api... was (Author: nickboldt): Further suggestion from Max/Doug: to allow loose coupling/watching by SOA Tooling jobs of upstream Core jobs, we might be able to use the URLTrigger plugin to watch MD5 hashes of update site zips, eg. http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_trunk.... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-10437: ------------------------------------ URLTrigger plugin now enabled in Jenkins. https://wiki.jenkins-ci.org/display/JENKINS/URLTrigger+Plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-10437: ---------------------------------------- Really? Good CI is CI that reacts quickly. A 6 hours feedback loop is too long to really benefit from CI. http://martinfowler.com/articles/continuousIntegration.html Every 6 hours is everything but ideal. How often are project affected by updatream change. Do we want "immediate" trigger in that case? These triggers introduce a lot of new builds which have the same results, This builds are part of what make Hudson so slow. What about immediate (~every 5 minutes) check of SVN to trigger jobs + 1 fixed time scheduled job daily, and no upstream triggering. So we have a 5 min + build time feedback loop for commit, and we have daily check for dependencies being compatible between them and with the code in SVN. This would create daily: As many builds as checkins (actually less, because checkins that happen during a running build create a single next build + As many builds as components. Daily, it would be about ~20 builds consequence of commits + ~20 builds consequence of scheduling. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-10437: ---------------------------------------- Because it cost *a lot* of resources for very limited added-value. Most changes happening in component are internal and do not affect other components. I counted commits based on actvity on the last days. It would be ~20 builds for the whole JBoss Tools for one day, not 800. Moreover, we can use a "every 3 days" scheduled build instead of a daily one. This scheduled build is only useful for inactive components that won't run builds for a long time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-10437 at 4/10/12 11:49 AM: -------------------------------------------------------------- Why schedule a build if the component is inactive? And why 3 days, if it's that slow? Why not weekly? As to API changes that break downstream, it happens. Especially in these stacks: common/tests, jsf/vpe/jst, maven/seam/hibernate. was (Author: nickboldt): Why schedule a build if the component is inactive? And why 3 days, if it's that slow? Why not weekly? As to API changes that break downstream, it happens. Especially in the common/tests, jsf/vpe/jst, maven/seam/hibernate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-10437: ------------------------------------ It varies. It's worse during the early milestones but but the time Beta1 drops, API changes should be few and far between. How about we implement a "quiet period" instead of having scheduled builds? That way we only change if SVN changes and if upstream is quiet enough to warrant a downstream spin. Right now the quiet period is "as soon as you can get a free slave an all upstream are done", but we could implement a several-hour quiet period to reduce the frequency of multiple builds being kicked due to upstream. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-10437: ---------------------------------------- Maybe the Build Pipeline plugin could help on that: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin This could be used to implement the process as described in jbt/trunk/build/diagrams. But I am still thinking that having no interlinkage between components would provide more agility and less Jenkins load for very few and rare drawbacks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-10437: ---------------------------------------- It will always be the case. I'm more wondering how fast we want feedback on this. Immediate feedback by cascading builds (what we have now) consume a lot of resources and time; a longer feedback (no cascading, SVN poll every 5 minutes + weekly schedule of all components) would make component build more reactive to changes inside component without adding so much meaningless builds. Also, as for static linkage of API, the continuous build already guarantees that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-10437: ---------------------------------------- Fix Version/s: 3.4.x (was: 3.3.0.CR1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-10437?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-10437 at 10/14/12 12:45 AM: --------------------------------------------------------------- Having a way to fire the whole stack of builds from a single operation is VERY handy when I have to do branch spins and respins. Right now I have to push the parent, target platforms, and tests build; that generally gets the whole thing going and I can just leave it alone to spin until done (or stalled due to failures). If we unlink all the builds, the wait time would be longer or I'd have to manually babysit each job until it was done to know when next to kick the downstream ones. I would much prefer to keep some degree of interlinking between jobs, but with the move to Git this will be easier as there will be fewer jobs. [~mickael_istria] Do you think we should just close this as rejected? or do you see stuff we can do to actually improve the workflow? Maybe we only want linkages in the stable_branch, but not trunk? was (Author: nickboldt): Having a way to fire the whole stack of builds from a single operation is VERY handy when I have to do branch spins and respins. Right now I have to push the parent, target platforms, and tests build; that generally gets the whole thing going and I can just leave it alone to spin until done (or stalled due to failures). If we unlink all the builds, the wait time would be longer or I'd have to manually babysit each job until it was done to know when next to kick the downstream ones. I would much prefer to keep some degree of interlinking between jobs, but with the move to Git this will be easier as there will be fewer jobs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira