Re: Buildbot screen per branch?
Filed a ticket: https://issues.apache.org/jira/browse/INFRA-5623 Daniel Shahaf wrote on Wed, Nov 21, 2012 at 11:42:26 +0200: Currently http://subversion.apache.org/buildbot contains a mixture of builds for all active branches (trunk, 1.6.x, 1.7.x). That makes it unfeasible to track the status of, say, the 1.6.x branch (which had a failure tonight - but that will be washed out soon by trunk commits and 1.7.x backport merges). We could split up each builder (column in http://subversion.apache.org/buildbot) into N builders, one per branch --- that adds no maintenance overhead (according to Gavin), and will allow us to easily monitor the status (and history) of each branch by adding a http://subversion.apache.org/buildbot-17x redirect that shows only the 1.7.x builders (at least N recent builds of each). WDYT? Daniel (Implementation-wise --- see mkcassbuilder() in cassandra.conf for an example.)
Buildbot screen per branch?
Currently http://subversion.apache.org/buildbot contains a mixture of builds for all active branches (trunk, 1.6.x, 1.7.x). That makes it unfeasible to track the status of, say, the 1.6.x branch (which had a failure tonight - but that will be washed out soon by trunk commits and 1.7.x backport merges). We could split up each builder (column in http://subversion.apache.org/buildbot) into N builders, one per branch --- that adds no maintenance overhead (according to Gavin), and will allow us to easily monitor the status (and history) of each branch by adding a http://subversion.apache.org/buildbot-17x redirect that shows only the 1.7.x builders (at least N recent builds of each). WDYT? Daniel (Implementation-wise --- see mkcassbuilder() in cassandra.conf for an example.)
Re: Buildbot screen per branch?
Daniel Shahaf wrote: Currently http://subversion.apache.org/buildbot contains a mixture of builds for all active branches (trunk, 1.6.x, 1.7.x). That makes it unfeasible to track the status of, say, the 1.6.x branch (which had a failure tonight - but that will be washed out soon by trunk commits and 1.7.x backport merges). We could split up each builder (column in http://subversion.apache.org/buildbot) into N builders, one per branch --- that adds no maintenance overhead (according to Gavin), and will allow us to easily monitor the status (and history) of each branch by adding a http://subversion.apache.org/buildbot-17x redirect that shows only the 1.7.x builders (at least N recent builds of each). WDYT? Sounds great. Yes please. It would also be useful to have a single view that shows all the latest builds on all the branches (in separate columns, unlike today), so there is single place to see at a glance whether any of the builds are failing. - Julian (Implementation-wise --- see mkcassbuilder() in cassandra.conf for an example.)
Re: Buildbot screen per branch?
Julian Foad wrote on Wed, Nov 21, 2012 at 13:18:22 +: Daniel Shahaf wrote: Currently http://subversion.apache.org/buildbot contains a mixture of builds for all active branches (trunk, 1.6.x, 1.7.x). That makes it unfeasible to track the status of, say, the 1.6.x branch (which had a failure tonight - but that will be washed out soon by trunk commits and 1.7.x backport merges). We could split up each builder (column in http://subversion.apache.org/buildbot) into N builders, one per branch --- that adds no maintenance overhead (according to Gavin), and will allow us to easily monitor the status (and history) of each branch by adding a http://subversion.apache.org/buildbot-17x redirect that shows only the 1.7.x builders (at least N recent builds of each). WDYT? Sounds great. Yes please. It would also be useful to have a single view that shows all the latest builds on all the branches (in separate columns, unlike today), so there is single place to see at a glance whether any of the builds are failing. Hmm. The waterfall page won't work for this --- it would require horizontal scrolling (to see all builders) and vertical scrolling (to see the latest build in each column). Something like http://ci.apache.org/one_line_per_build perhaps, if we can restrict it to our set of builders. Daniel - Julian (Implementation-wise --- see mkcassbuilder() in cassandra.conf for an example.)
