Bug 98957 – Need a cr-linux debug EWS bot

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Ojan Vafai]

We don't want the bots to be debug because then they'd be too slow. But running with just asserts enabled would probably be the sweet spot of catching debug-only test failures and still being fast to run.

[Ojan Vafai]

Eric convinced me that all I really want it a debug EWS bot.

[Adam Barth]

This is easy to set up.  We just need server resources.

[Eric Seidel (no email)]

This keeps coming up.  Folks break the debug build (compile) by accident.  It's very easy to do.

[Alan Cutter]

The main blocker here is server resources. I'm still waiting for a response from GCE on a request for more instance & CPU quota. I assume we would need at least as many bots as are on the chromium-ews queue (8 bots). We are currently using 13/16 bots in GCE.

[Eric Seidel (no email)]

I don't think we actually will need that many.  Build-only doesn't take very long.  If we fixed the existing EWS to not spin so much I suspect we'd have more than enough machines already. :)

[Tony Chang]

There are some build stats on the chromium waterfall:
http://build.chromium.org/p/chromium.webkit/stats/WebKit%20Linux
http://build.chromium.org/p/chromium.webkit/stats/WebKit%20Linux%20%28dbg%29

It looks like compile times are comparable.  The big difference is the time it takes to run webkit_tests.  On the release bot, it's around 420sec and on the debug bot it's 935sec.  Since we skip flaky tests, it's not going to be exactly the same.  Also, it looks like the release bot has 8 cores and the debug bot has 24 cores.

Hmm, I guess it's not clear to me how much slower the debug bot is going to be, but it looks like at least 2x.

[Tony Chang]

Oh, you just want compile only.  Yeah, looks like that should be pretty fast.  Maybe 3x slower considering that the debug build.chromium.org has 3x the number of cores, but I doubt it will be that much in practice.

[Alan Cutter]

Ah, I didn't know this was just for building, in that case 2 bots should probably be enough.

[Alan Cutter]

Created attachment 185379 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 185379 [details]
Patch

OK.  LGTM.  We really should store the list of queues in the data store one of these days. :)

[Eric Seidel (no email)]

bubbles are hitting an exception:
Traceback (most recent call last):
  File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/_webapp25.py", line 714, in __call__
    handler.get(*groups)
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 78, in get
    bubbles, show_submit_to_ews = self._build_bubbles_for_attachment(attachment)
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 62, in _build_bubbles_for_attachment
    if not self._have_status_for(attachment, queue):
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 53, in _have_status_for
    if attachment.position_in_queue(queue):
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 81, in position_in_queue
    return self._queue_positions().get(queue.name())
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 97, in _queue_positions
    self._cached_queue_positions = self._calculate_queue_positions()
  File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 102, in _calculate_queue_positions
    return dict([(items.queue.name(), items.display_position_for_attachment(self.id)) for items in all_work_items])
AttributeError: 'NoneType' object has no attribute 'name'

Is that from this push?

[Alan Cutter]

(In reply to comment #11)
> bubbles are hitting an exception:
> Traceback (most recent call last):
>   File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/_webapp25.py", line 714, in __call__
>     handler.get(*groups)
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 78, in get
>     bubbles, show_submit_to_ews = self._build_bubbles_for_attachment(attachment)
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 62, in _build_bubbles_for_attachment
>     if not self._have_status_for(attachment, queue):
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/handlers/statusbubble.py", line 53, in _have_status_for
>     if attachment.position_in_queue(queue):
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 81, in position_in_queue
>     return self._queue_positions().get(queue.name())
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 97, in _queue_positions
>     self._cached_queue_positions = self._calculate_queue_positions()
>   File "/base/data/home/apps/webkit-commit-queue/107659.364926346735440376/model/attachment.py", line 102, in _calculate_queue_positions
>     return dict([(items.queue.name(), items.display_position_for_attachment(self.id)) for items in all_work_items])
> AttributeError: 'NoneType' object has no attribute 'name'
> 
> Is that from this push?

That was from me viewing the "pre-release" version causing a WorkItem to be created for the cr-linux-debug-ews queue which still doesn't exist in production causing a None to be let loose in the system. My mistake!

(In reply to comment #10)
> (From update of attachment 185379 [details])
> OK.  LGTM.  We really should store the list of queues in the data store one of these days. :)

This sounds like a good idea and should avoid the aforementioned scenario!

[WebKit Review Bot]

Comment on attachment 185379 [details]
Patch

Clearing flags on attachment: 185379

Committed r141223: <http://trac.webkit.org/changeset/141223>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.