Progressbars non-TTY UX issues

[na--]

While investigating #1579, I noticed a few inconsistencies in how we display the new progressbars in non-TTY mode. If I run k6 run github.com/loadimpact/k6/samples/http_get.js 2>&1 | cat, to simulate non-TTY, I get something like:

          /\      |‾‾|  /‾‾/  /‾/   
     /\  /  \     |  |_/  /  / /    
    /  \/    \    |      |  /  ‾‾\  
   /          \   |  |‾\  \ | (_) | 
  / __________ \  |__|  \__\ \___/ .io

 Init   [--------------------------------------] runner
 Init   [--------------------------------------] options
 Init   [--------------------------------------] execution scheduler
Init   [--------------------------------------] Init engine
Init   [--------------------------------------] Init metric outputs
Init   [--------------------------------------] Init API server
  execution: local
     script: github.com/loadimpact/k6/samples/http_get.js
     output: -

  scenarios: (100.00%) 1 executors, 1 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 1 iterations for each of 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)

Init   [--------------------------------------] Init VUs
Init   [--------------------------------------] Start test

running (00m01.0s), 1/1 VUs, 0 complete and 0 interrupted iterations
default   [   0% ] 1 VUs  00m01.0s/10m0s  0/1 iters, 1 per VU


running (00m01.1s), 0/1 VUs, 1 complete and 0 interrupted iterations
default ✓ [ 100% ] 1 VUs  00m01.1s/10m0s  1/1 iters, 1 per VU


    data_received..............: 18 kB 15 kB/s
    ...

There are several inconsistencies:

• Init has a space before it in the first 3 rows and then it doesn't
• The status text in these first 3 rows is not capitalized and isn't very clear, I assume runner and options means nothing to the average k6 user 😅
• We're initially displaying an ASCII progressbar (though, we probably don't really need a progressbar before Init VUs), but then we switch to a percentage based progressbar (which makes a lot more sense for non-TTY runs)...

For sure, things can be better once we implement #1376 - having the current responsive, 100ms refresh-rate progresbars for TTY k6 runs, and a log-based progress report every few seconds for non-TTY (i.e. mostly CI) k6 runs. But until then we can at least fix the inconsistencies we currently have...

[na--]

k6 cloud github.com/loadimpact/k6/samples/http_get.js 2>&1 | cat is slightly better, but it also has some minor issues:

          /\      |‾‾|  /‾‾/  /‾/   
     /\  /  \     |  |_/  /  / /    
    /  \/    \    |      |  /  ‾‾\  
   /          \   |  |‾\  \ | (_) | 
  / __________ \  |__|  \__\ \___/ .io

 Init   [--------------------------------------] Parsing script
 Init   [--------------------------------------] Getting script options
 Init   [--------------------------------------] Consolidating options
 Init   [--------------------------------------] Building the archive
 Init   [--------------------------------------] Validating script options
 Init   [--------------------------------------] Uploading archive
  execution: cloud
     script: github.com/loadimpact/k6/samples/http_get.js
     output: https://app.k6.io/runs/783049

  scenarios: (100.00%) 1 executors, 1 max VUs, 10m30s max duration (incl. graceful stop):
           * default: 1 iterations for each of 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)

 Run    [--------------------------------------] Initializing the cloud test
 Run    [--------------------------------------] Created
 Run    [--------------------------------------] Validated
 Run    [--------------------------------------] Validated
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] Initializing
 Run    [--------------------------------------] 00m00.0s/10m30s
 Run    [--------------------------------------] 00m01.9s/10m30s
 Run    [--------------------------------------] 00m03.9s/10m30s
 Run    [--------------------------------------] 00m05.9s/10m30s
 Run    [--------------------------------------] 00m07.9s/10m30s
 Run    [--------------------------------------] 00m10.0s/10m30s
 Run    [--------------------------------------] 00m12.0s/10m30s
 Run    [--------------------------------------] 00m13.9s/10m30s
 Run    [--------------------------------------] 00m15.9s/10m30s
 Run    [--------------------------------------] 00m18.0s/10m30s
 Run    [--------------------------------------] 00m19.9s/10m30s
 Run    [--------------------------------------] 00m22.0s/10m30s
 Run    [--------------------------------------] 00m24.0s/10m30s
 Run    [--------------------------------------] 00m26.0s/10m30s
 Run    [--------------------------------------] 00m27.9s/10m30s
 Run    [--------------------------------------] 00m29.9s/10m30s
 Run    [--------------------------------------] 00m31.9s/10m30s
 Run    [--------------------------------------] 00m34.0s/10m30s
 Run    [--------------------------------------] 00m36.0s/10m30s
 Run    [--------------------------------------] 00m37.9s/10m30s
 Run    [--------------------------------------] 00m39.9s/10m30s
 Run    [--------------------------------------] 00m41.9s/10m30s
 Run    [--------------------------------------] 00m44.0s/10m30s
 Run    [--------------------------------------] 00m45.9s/10m30s
 Run    [--------------------------------------] 00m48.1s/10m30s
 Run    [--------------------------------------] 00m49.9s/10m30s
 Run    [--------------------------------------] 00m52.0s/10m30s
 Run    [--------------------------------------] 00m54.0s/10m30s
 Run    [--------------------------------------] 00m55.9s/10m30s
 Run    [--------------------------------------] 00m57.9s/10m30s
 Run    [--------------------------------------] 01m00.0s/10m30s
 Run    [--------------------------------------] 01m01.9s/10m30s
 Run    [--------------------------------------] 01m03.9s/10m30s
 Run    [--------------------------------------] 01m05.9s/10m30s
 Run    [--------------------------------------] Finished
     test status: Finished

• Run and Init also have some indentation before them. It actually doesn't look bad since it's consistent, but it also doesn't really look better than no indentation IMO 🤷‍♂️
• The actual progress doesn't seem to get updated at all. That said, this progressbar is never going to be accurate anyway, since the test only makes a single iteration and most of the actual waiting here is for cloud initialization and finalization information to percolate, but still, if we're counting time on the right, we should move the progressbar's progress as well

[gygitlab]

Came here to raise exactly this. The non-TTY output in 0.26 was a bit better and the whitespaces around the progress updates are a bit much to my eyes:

running (00m01.0s), 1/1 VUs, 0 complete and 0 interrupted iterations
default   [   0% ] 1 VUs  00m01.0s/10m0s  0/1 iters, 1 per VU
<whitespace>
<whitespace>
running (00m01.1s), 0/1 VUs, 1 complete and 0 interrupted iterations
default ✓ [ 100% ] 1 VUs  00m01.1s/10m0s  1/1 iters, 1 per VU

Happy to see the team is on it @na--!