To test the jsc armv7 EWS, I made a patch that would make all the tests fail on arm. This patch has already been tested 9x2 times on the bot, as can be seen in https://webkit-queues.webkit.org/patch/352475/jsc-armv7-ews. For now, I've removed the "r?" from the patch, hoping that it will remove it from the list, but I think this might be revealing an issue with reporting a very high number of test failures.
This is definitely a case that's supposed to work in general. It may be that JSC support has a bug in this code path, or some edge case that gets triggered for this specific result set. Could you please check logs on the bot for any signs of trouble? Those are not uploaded anywhere, so we cannot see them.
Finally found some time to start investigating that. Looking through my 26GB log file, I found this: after the bot has processed the patch (running twice with the patch + once without it to confirm that tests pass without the patch) and got failures, it seems to fail in the step where it tries to post a message on the bug. Here is an extract from the log, it was listing the tests that failed (most tests as I made a patch specifically for this on #190428), and then this: stress/put-by-id-direct-strict-transition.js.no-cjit-validate-phases stress/sink-to-impossible-multi-get-by-offset-on-prototypes.js.dfg-maximal-flush-validate-no-cjit stress/arrowfunction-others.js.no-cjit-collect-continuously sunspider-1.0/access-nbody.js.no-llint apiTests Traceback (most recent call last): File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/tool/bot/queueengine.py", line 103, in run if not self._delegate.process_work_item(work_item): File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/tool/commands/queues.py", line 479, in process_work_item passed = self.review_patch(patch) File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py", line 120, in review_patch self._post_reject_message_on_bug(self._tool, patch, task.failure_status_id, self._failing_tests_message(task, patch)) File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py", line 95, in _post_reject_message_on_bug tool.bugs.set_flag_on_attachment(patch.id(), "commit-queue", "-", message) File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/common/net/bugzilla/bugzilla.py", line 822, in set_flag_on_attachment self._find_select_element_for_flag(flag_name).value = (flag_value,) File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/common/net/bugzilla/bugzilla.py", line 786, in _find_select_element_for_flag return self.browser.find_control(type='select', nr=1) File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_form.py", line 3101, in find_control return self._find_control(name, type, kind, id, label, predicate, nr) File "/home/buildbot/ews/WebKit/Tools/Scripts/webkitpy/thirdparty/autoinstalled/mechanize/_form.py", line 3185, in _find_control raise ControlNotFoundError("no control matching "+description) ControlNotFoundError: no control matching type 'select', nr 1 2019-04-08 06:51:20,519 - Exception while preparing queue Sleeping until 2019-04-08 06:53:20 (120 seconds). 2019-04-08 06:53:20,520 - Fetching next work item for jsc-armv7-ews After that it goes onto the next patch in the queue, but it seems that the faulty patch gets added to the end of the queue.
The issue seems to stem from the fact that the ews bugzilla user (guijemont+jsc-armv7-ews@igalia.com) does not have commit rights in bugzilla, therefore the box to set the commit queue status does not exist on the page that it gets.
Can confirm thanks to #190428 that adding the editbugs privilege to the EWS bugzilla user solved the issue.
(In reply to Guillaume Emont from comment #4) > Can confirm thanks to #190428 that adding the editbugs privilege to the EWS > bugzilla user solved the issue. In other conditions, I'd file a bug on the EWS for not providing a better error message/checking for that specific issue, but since it's being replaced, that's probably not worth it.