fix: reduce curl container log output to single line status

[moko-poi]

Summary

Reduces curl container log output from verbose multi-line format to a clean single-line status format as requested in issue #653.

Changes

Modified curl commands in curl_start.go and curl_stop.go to include -o /dev/null -s -w '{http_code="%{http_code}"}\n' flags

Before

❯ kubectl logs k6-curl-test-starter-bxwx6  
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   237  100   150  100    87  36443  21137 --:--:-- --:--:-- --:--:-- 79000
{"data":{"type":"status","id":"default","attributes":{"status":4,"paused":false,"vus":0,"vus-max":1,"stopped":false,"running":false,"tainted":false}}}%

After

❯ k logs k6-curl-test-starter-r882m                                                                                                                                    ─╯
{"data":{"type":"status","id":"default","attributes":{"status":4,"paused":false,"vus":0,"vus-max":1,"stopped":false,"running":false,"tainted":false}}}
{"http_code":200,"time_total":0.004452,"time_starttransfer":0.004441,"url":"http://10.96.244.19:6565/v1/status","remote_ip":"10.96.244.19"}

Testing

• Verified the change works as expected with k6 curl test containers
• Log output is now concise and easier to parse while maintaining essential status information

Fixes #653

[moko-poi]

@yorugac
I've implemented it this way and the output looks like this:

{"data":{"type":"status","id":"default","attributes":{"status":4,"paused":false,"vus":0,"vus-max":1,"stopped":false,"running":false,"tainted":false}}}
{"http_code":200,"time_total":0.004452,"time_starttransfer":0.004441,"url":"http://10.96.244.19:6565/v1/status","remote_ip":"10.96.244.19"}

How does this look? Please let me know if you have any feedback, such as:

• Whether we should combine them into a single JSON structure
• If any of the metadata fields are unnecessary
• If the response body should be omitted

[yorugac]

Thanks for the PR, @moko-poi!
Have you checked what kind of output this change would get on an error scenario too?

[moko-poi]

Hi @yorugac!

Yes, I've tested the error scenario as well. Here's what the output looks like when the starter curl fails to connect to the k6 runner

{"http_code":000,"time_total":0.000931,"time_starttransfer":0.000000,"url":"http://10.96.120.142:6565/v1/status","remote_ip":""}

This structured JSON format makes it much easier to diagnose connection issues compared to the previous simple {http_code="000"} output, providing additional timing and network-level details for troubleshooting.

[yorugac]

Thanks, @moko-poi!

So on error it's just one line, not two?
Also, what does code "000" mean? 😅 I don't think this is the right output for the error...

[moko-poi]

Hi @yorugac,

The test I conducted was specifically for the scenario where the k6 runner is not running, causing the start operation to fail. In this case:

1. Connection failure: Since the k6 runner is not available, curl cannot establish a connection to the target endpoint
2. No response body: Because the connection fails, there is no HTTP response body from the k6 server
3. HTTP code 000: This is curl's standard behavior when no HTTP response is received (connection refused, DNS failure, etc.)

So the single-line output {"http_code":"000",...} is the correct and expected behavior for this error scenario. The "000" code is curl's way of indicating that no actual HTTP status code was received from the server.

See: https://stackoverflow.com/questions/9791684/what-is-http-status-code-000

[moko-poi]

Additionally, I've also tested scenarios where k6 is running but returns HTTP errors using the exact same curl commands as our starter/stopper containers:

HTTP Error Response Test (k6 running but returning errors)

Using the exact starter command from curl_start.go

curl --retry 3 -X PATCH -H 'Content-Type: application/json' http://k6:6565/v1/status -d '{"data":{"attributes":{"paused":false},"id":"default","type":"status"}}' -s -w '...'

Result (HTTP 500)

{"errors":[{"status":"500","title":"Pause error","detail":"ramping-vus executor 'default' doesn't support pause and resume operations after its start"}]}
{"http_code":"500","time_total":0.000832,"url":"http://k6:6565/v1/status","remote_ip":"10.96.220.129"}

Successful stopper command test

{"data":{"type":"status","id":"default","attributes":{"status":7,"paused":false,"vus":1,"vus-max":1,"stopped":true,"running":true,"tainted":false}}}
{"http_code":"200","time_total":0.000820,"url":"http://k6:6565/v1/status","remote_ip":"10.96.220.129"}

[yorugac]

Hi @moko-poi, thanks for the details.
I think I've found how to add the readable error here:
https://daniel.haxx.se/blog/2021/01/27/curl-your-own-error-message/

%{errormsg}: it seems to work as expected, AFAIS. Could you please add that one?
I think we should as explicit as possible on error scenarios, esp. given that this error means a networking problem within a cluster.

[moko-poi]

Thank you @yorugac !
Added %{errormsg}

[yorugac]

Thanks for the update, @moko-poi!

There is now a failing Zizmor check: I've fixed it in the PR #663. Now this PR, 654, for curl containers, does not change any of .github/ files and the failure came from the Zizmor version update in the shared workflow. So I'm merging it.