[Webkit-unassigned] [Bug 29062] Consider integrating commit-queue with chromium try servers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29062


Marc-Antoine Ruel <maruel at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maruel at chromium.org




--- Comment #6 from Marc-Antoine Ruel <maruel at chromium.org>  2009-09-09 08:47:03 PDT ---
Setup:
I highly recommend to use a separate master for try jobs. Since slaves are more
frequently added, removed and configuration changes occurs more frequently,
it's better to not constantly break the continuous build, especially during the
initial setup. The try server config could be in
http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/try.webkit.org-config
or something similar, depending on the host name you choose.


Maintenance:
Note that the current chromium's try server is not maintenance free so the
slaves need a way to be fixed manually from time to time. Since webkit's tests
aren't as messy as chromium's ones, it shouldn't be too frequent. Having slaves
dispersed across the global doesn't help.


Triggering:
You guys need to decide what method is used to triggers try jobs. Example ways
are:
- a patch checked-in in a specific svn repository that is polled by buildbot
(implemented)
- a direct http PUSH to the master (implemented, fast but unsafe)
- bugzilla poll on the master (probably best with webkit workflow but not
implemented, probably similar to commit queue)
- buildbot try (requires users to have buildbot+twisted code locally, not
preferred, at least not to me)

I don't think anyone wants to open a http port directly to the buildbot master
for try jobs. I think having a trigger directly from bugzilla would be
interesting. I'm not used to the webkit workflow so I can't tell which method
is better.


Access control:
I'd say you'd probably want to limit try job trigger to webkit committers.
That's what we do. A committer can send a try job on behalf of a contributor.


Hosting:
Google will provide slaves for multiple platforms in a DMZ. We may not have
full coverage but we definitely can help. Dimitry may tell more about his
plans.


Try server stuffing and supported platforms:
If try job scheduling is manual, 2 per platform would be sufficient. If the try
jobs are automatically triggered by bugzilla patch updates, I'd say around 8
per platform depending on speed and real usage.

In any case, it's better to start with manual trigger for a few week to see
rough usage and fix issues and make it automatic IIF concluding. It's easier to
start with a small amount of slaves and scale accordingly. I'd propose to start
with 8 platforms:
(apple) mac leopard intel debug
(apple) windows debug
gtk linux release
qt linux release
chromium win debug
chromium mac debug
chromium linux debug

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.