-
Notifications
You must be signed in to change notification settings - Fork 160
Feat; attempt at rendering new status page #2227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Collectors look good! In terms of the queue, could you just reuse the old UI? I don't think that we need to change much there, the timeline was IMO working quite well. So I would transplant the old timeline here, move it to the left side of the page, and then show the collector and job state on the right side of the page.
I don't think that we need to show the individual steps anymore, it would be too much information IMO. So no need to load data from pstats or collector_progress (in fact I would remove collector_progress
later).
BenchmarkRequestComplete
, BenchmarkRequestInProgress
and BenchmarkRequestArtifactsReady
can be unified into just BenchmarkRequest
.
@@ -1,42 +1,55 @@ | |||
export const BenchmarkRequestComplete = "completed"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that these constants are needed. This is one of the benefits of TS vs Rust, that it has string value as actual types. So you don't need the constant, you can just use the string literal (it's easier to read "completed"
than typeof BenchmarkRequestComplete
), and it will still be type-checked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. I generally avoid using magic strings because modifying them across multiple locations can be tedious and error-prone. I'm happy to update everything to magic strings if that's your preference, though I personally prefer symbolic constants
e8c2545
to
dd01567
Compare
Hmm, interesting, I don't need the
|
This seems to pass in the pipeline? |
76315ec
to
d420fc1
Compare
Something wrong with bench durations on https://perf.rust-lang.org/status.html page, for example cargo:
clearly bench didn't run 0.4 sec. |
Thanks! #2232 fixes it. |
Caveat; I'm no UI designer/programmer.
An attempt at rendering something more useful on the new status page;
I think we may want to do a join from; job -> items in a benchmark set -> pstats. Then we can see what is going on at the job level. Also to give an estimate we'd want to do the same kind of query but take a sample of completed "pstats" to work out the duration per "pstat" that is currently in flight. We could then also estimate how long a job would take from that sample.
With in_progress requests
Idle collectors