[Webkit-unassigned] [Bug 258920] New: [browserperfdash-benchmark] Implement optional parameter to send benchmark data with the timestamp of the git checkout and use it on the bots

[bugzilla-daemon at webkit.org]

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

            Bug ID: 258920
           Summary: [browserperfdash-benchmark] Implement optional
                    parameter to send benchmark data with the timestamp of
                    the git checkout and use it on the bots
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: bugs-noreply at webkitgtk.org

Since 249031 we are running performance tests with multiple RPis in parallel.

And there is a potential issue that can happen because there are several workers for each performance bot working in parallel.

Bot1 starts testing commit 1234 at main
Bot2 starts testing commit 1245 at main

Bot2 ends before than Bot1 -> The data on the dashboard will appear as if commit 1245 at main happened before than 1234 at main because the dashboard doesn't use the browser_version (or commit revision) to sort the data.
The dashboard sorts the data by the timestamp. And the runner (the bot) defaults to sends automatically a timestamp with the date of when it finish testing.


To overcome this problem we can implement a way of sending the data with the timestamp of the checked_out git commit (HEAD).

That way we can also re-run performance tests on old checkouts and the data will be sent to the server with the right timestamp.

We don't really care about when the performance test was executed, in reality we should care about the commit date of the commit that we have built (that is the one checked out).

-- 
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/20230706/a2d752ca/attachment-0001.htm>