[Webkit-unassigned] [Bug 190188] Add retry for test groups with failed build requests.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 2 01:34:24 PDT 2018


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

Ryosuke Niwa <rniwa at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #351353|review?                     |review-
              Flags|                            |

--- Comment #2 from Ryosuke Niwa <rniwa at webkit.org> ---
Comment on attachment 351353
  --> https://bugs.webkit.org/attachment.cgi?id=351353
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=351353&action=review

> Websites/perf.webkit.org/ChangeLog:18
> +                ADD COLUMN testgroup_expected_successful_build_requests integer DEFAULT NULL,
> +                ADD COLUMN testgroup_may_need_additional_build_requests boolean DEFAULT FALSE;

These names are too long. How about just: testgroup_iteration_count & testgroup_may_need_more_requests.

> Websites/perf.webkit.org/public/api/build-requests.php:77
> +    if (count($test_groups_may_need_additional_build_requests))
> +        $db->query('UPDATE analysis_test_groups SET testgroup_may_need_additional_build_requests = TRUE WHERE testgroup_id = ANY($1)',
> +            array('{' . implode(',', array_keys($test_groups_may_need_additional_build_requests)) . '}'));

I don't think we need to coerce queries like this.
Just issue a SQL query per build request.
We can certainly have a map which stores the set of test groups we've already set this flag.

> Websites/perf.webkit.org/public/api/test-groups.php:25
> -    } elseif ($path[0] == 'ready-for-notification') {
> +    } elseif ($path[0] == 'ready-for-further-processing') {

I think we should just add a new API surface instead of replacing an existing one.

> Websites/perf.webkit.org/public/privileged-api/update-test-group.php:19
> +        if (array_key_exists('name', $data) || array_key_exists('hidden', $data) || array_key_exists('mayNeedAdditionalBuildRequests', $data))
> +            exit_with_error('TooManyArgumentsProvided');

Why don't we add a new dedicated API instead?
I think that'd be cleaner than re-using this API and having restrictions like these.

> Websites/perf.webkit.org/public/privileged-api/update-test-group.php:28
>          $values['hidden'] = Database::to_database_boolean($data['hidden']);
> +        $values['may_need_additional_build_requests'] = FALSE;

I think we probably want another check at where we create build requests
that we haven't recently canceled this test group.

> Websites/perf.webkit.org/public/privileged-api/update-test-group.php:58
> +        for ($i = 0; $i < $additional_build_request_count; $i++) {
> +            $processed_commit_set = array();

Why don't we split the part to find the list of commit sets in this group into a separate helper function?

> Websites/perf.webkit.org/public/v3/models/test-group.js:14
> +        this._mayNeedAdditionalBuildRequests = object.mayNeedAdditionalBuildRequests;
> +        this._expectedSuccessfulBuildRequests = object.expectedSuccessfulBuildRequests;

Let's also shorten these names.

> Websites/perf.webkit.org/public/v3/models/test-group.js:231
> +    async addBuildRequests(buildRequestCount)

Just call it "count".

> Websites/perf.webkit.org/public/v3/models/test-group.js:239
> +    async clearNeedAdditionalBuildRequestsFlag()

No need to say "flag".

> Websites/perf.webkit.org/server-tests/resources/mock-data.js:67
> +    addMockData: function (db, statusList, needs_notification=true)

Use camelCase.

> Websites/perf.webkit.org/server-tests/resources/mock-data.js:82
> +            db.insert('analysis_test_groups', {id: 600, task: 500, name: 'some test group', expected_successful_build_requests: 4, needs_notification}),

Ditto here and elsewhere in this test.

> Websites/perf.webkit.org/tools/run-analysis.js:19
> +        {name: '--max-retry-ratio', type: parseFloat, default: 2.5},

Maybe even 3 might be okay.

> Websites/perf.webkit.org/tools/run-analysis.js:67
> +async function processTestGroupsNeedAdditionalBuildRequests(testGroups, maximumRetryRatio)

I don't think we want to use vague terms like "processing".
Let's just say createAdditionalBuildRequestsForTestGroupsWithFailedRequests or something.
We can use a verbose name here.

> Websites/perf.webkit.org/tools/run-analysis.js:80
> +        let maxMissingSuccessfulBuildRequestCount = 0;
> +        for (const commitSet of this.requestedCommitSet()) {
> +            const buildRequests = testGroup.requestsForCommitSet(commitSet);
> +            maxMissingSuccessfulBuildRequestCount = Math.max(maxMissingSuccessfulBuildRequestCount, buildRequests.filter((buildRequest) => !buildRequest.hasCompleted()).length);
> +        }

I don't think this logic is quite right.
buildRequest.hasCompleted() returns false for pending & canceled requests.
r- because of this.

In fact, we probably want to make sure this code handles the case when some request are still pending, scheduled, or canceled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181002/f8f91cd1/attachment-0001.html>


More information about the webkit-unassigned mailing list