Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 78f48dc7101088e81d3c32ca7d9b88f6d12276b5
https://github.com/WebKit/WebKit/commit/78f48dc7101088e81d3c32ca7d9b88f6d12276b5
Author: Issac Roy <[email protected]>
Date: 2026-09-03 (Thu, 03 Sep 2026)
Changed paths:
M Tools/CISupport/ews-build/results_db.py
M Tools/CISupport/ews-build/steps.py
M Tools/CISupport/ews-build/steps_unittest.py
Log Message:
-----------
[EWS] EWS ResultsDB reading and writing should be typed
https://bugs.webkit.org/show_bug.cgi?id=323144
rdar://186403771
Reviewed by Aakash Jain.
The results database helpers grew from a handful of query functions into the
path that decides whether a pull request gets blamed for a test failure, and
they pass that data around as bare dicts. A row's provenance is reached through
`(row.get('details') or {}).get('authors')` at four call sites, each repeating
the same guard against a key the server may omit, and nothing states what a row
or an upload contains.
`EWSRowDetails`, `EWSRow` and `EWSPayload` name those three shapes. `EWSRow`
holds a parsed `details`, so the guards collapse into attribute access and the
one place that filters empty author names is `EWSRowDetails.from_json`.
`report_ews` takes an `EWSPayload` rather than seven keyword arguments, and
`_query_flaky` returns `EWSRowByTest`, parsing the response into rows once
instead of leaving every consumer to walk `entry['results']`.
`EWSPayload` deliberately has no `api_key` field. The payload is logged, and a
field would put the live key in every `__repr__` of it; `report_ews` injects the
key into the request body alone. The request dump no longer substitutes a
redacted key either, since the dict it prints never held one.
Results blobs, `configuration` and `commits` stay `dict` below the top level.
They are results database JSON whose keys vary by suite and by which
configuration dimensions a queue supplies, so naming fields would be a lie
rather than a gap. `_parse_results_ews_response` still returns raw dicts for the
same reason: it is deliberately the pre-validation shape, converted to `EWSRow`
immediately after.
`report_ews`, `_query_flaky` and `flaky_verdicts_for` are `inlineCallbacks`
generators, so they carry `Generator[Any, Any, T]` describing the body rather
than the `Deferred` the decorator hands the caller, matching what the tests in
`steps_unittest.py` already do.
`_is_intra_build_flake` no longer guards against an empty flaky type. The only
producer of those keys is `_rows_by_type`, which buckets every row under
`row.flaky_type or cls.FAILED_ROWS`, so a key is never empty.
* Tools/CISupport/ews-build/results_db.py:
(EWSRowDetails):
(EWSRowDetails.from_json):
(EWSRowDetails.to_json):
(EWSRow):
(EWSRow.from_json):
(EWSPayload):
(EWSPayload.to_json):
(ResultsDatabase.report_ews):
(ResultsDatabase._evidence_in):
(ResultsDatabase._rows_by_type):
(ResultsDatabase._rows_by_type.independent_of_this_pull_request):
(ResultsDatabase._rows_by_type.independent_of_this_changes_authors):
(ResultsDatabase._is_intra_build_flake):
(ResultsDatabase._is_inter_build_flake):
(ResultsDatabase._parse_results_ews_response):
(ResultsDatabase._query_flaky):
(ResultsDatabase.flaky_verdicts_for):
* Tools/CISupport/ews-build/steps.py:
(ResultsDBReportMixin.results_db_details):
(ResultsDBReportMixin.report_to_results_db):
* Tools/CISupport/ews-build/steps_unittest.py:
(BuildStepMixinAdditions.setup_test_build_step.record_report_ews):
(TestReportToResultsDB.test_an_unreachable_results_database_does_not_fail_the_step.explode):
(TestResultsDatabaseFailureHandling._mock_twisted_request):
(TestResultsDatabaseFailureHandling.report_ews):
(TestResultsDatabaseFailureHandling.test_report_ews_logs_the_request_without_the_api_key):
Canonical link: https://commits.webkit.org/320412@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
