-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix cloud test progress status in CLI #1490
Conversation
Codecov Report
@@ Coverage Diff @@
## new-schedulers #1490 +/- ##
==================================================
- Coverage 77.33% 77.15% -0.18%
==================================================
Files 162 162
Lines 13127 13155 +28
==================================================
- Hits 10152 10150 -2
- Misses 2455 2485 +30
Partials 520 520
Continue to review full report at Codecov.
|
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.
Hmm to be honest, I'm not sure if I like the shifting text on the left 😕 Maybe we can have 2/3 fixed-width labels on the left, Init
/ Run
/ Done
, and keep showing the detailed run status text on the right? cc @mpandurovic
@na-- Yeah, that might make more sense to bring it in line with the I added the elapsed/total time while the test is running, since showing Here's what it looks like on 66b0ad7a. Let me know if this should be refined or if we should just hide "Running" on the right side and not bother with the time. EDIT: Pushed a fix in 5d27e4b to hopefully address all duration scenarios. |
6dab874
to
5d27e4b
Compare
05a4528
to
e931fc2
Compare
In order to reuse SumStagesDuration and move it to lib, I had to remove the duplicate executor.Stage definition, and reuse the one in lib, which might be cleaner anyway.
…ud PBs Maybe resolves #1488 (comment)
This now also prints a more detailed execution description for cloud tests. Resolves #1490 (comment)
This reverts commit 74cf031. Resolves #1490 (comment)
6df9b4b
to
cc01c16
Compare
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.
Mostly LGTM, though I don't like the extra GetFullExecutionRequirements()
calculation in the case of k6 run
... That can be very costly for large test runs, especially if we have a ramping-vus
executor... We'd just be adding one more layer to #1499 / #1427...
So, despite printExecutionDescription()
having a ton of parameters, I think we should add one more for now, and pass the already pre-calculated execScheduler.GetExecutionPlan()
in k6 run
, so we don't have another performance degradation. But we should also make a note in #1499 and/or #1427 to clean it up when we refactor the APIs and clean up the other issues.
Closes #1488
It's still a bit janky, but at least it shows the status text in the same place as before. Please test it out locally and let me know.