k6 should successfully run load tests in a container
k6 crashes with the following stack trace:
execution: local
script: /scripts/debug.bundle.js
output: json=test_results.json
scenarios: (100.00%) 1 executors, 10 max VUs, 1m30s max duration (incl. graceful stop):
* default: Up to 10 looping VUs for 1m0s over 3 stages (gracefulRampDown: 30s, gracefulStop: 30s)
panic: runtime error: integer divide by zero--] Init VUs
goroutine 6 [running]:
github.com/loadimpact/k6/cmd.renderMultipleBars(0xc007600101, 0x7, 0x0, 0x0, 0xc002678000, 0x2, 0x2, 0x5327a4, 0xd1fce0, 0x0)
github.com/loadimpact/k6/cmd/ui.go:218 +0xda9
github.com/loadimpact/k6/cmd.showProgress.func2(0xc003713101)
github.com/loadimpact/k6/cmd/ui.go:283 +0x8c
github.com/loadimpact/k6/cmd.showProgress(0x10d8a40, 0xc000d94100, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc00159cd80, ...)
github.com/loadimpact/k6/cmd/ui.go:352 +0x52a
github.com/loadimpact/k6/cmd.glob..func11.1(0x10d8a40, 0xc000d94100, 0xc0005d6300, 0xc0009a2500, 0xc0001b2000, 0xc000ec4bd0)
github.com/loadimpact/k6/cmd/run.go:190 +0xb9
created by github.com/loadimpact/k6/cmd.glob..func11
github.com/loadimpact/k6/cmd/run.go:189 [+0xd34]
This seems similar to https://github.com/loadimpact/k6/issues/1559 as it is unable to get the terminal width correctly, but 0.27.1 did not fix the issue in CodeFresh, and still crashes in the same way. Reverting to 0.26.2 works as expected.
Attempting to run any script on a k6 0.27.0 or 0.27.1 container in CodeFresh should see this behavior.
... :sob: Sorry for this and thanks for reporting it! :disappointed:
I have never used CodeFresh, but assume this is it's some weird edge case where 1) k6 doesn't detect it's not running in a TTY (or maybe CodeFresh provides some pseudo-TTY :man_shrugging: ) and 2) trying to get the size of the terminal doesn't return an error, but returns 0 instead...
We should probably change this check and others like it:
https://github.com/loadimpact/k6/blob/8f4797d2761560fefb3e01c1bf440ee6a1c55548/cmd/ui.go#L257-L262
To check for an error or termWidth equals to 0?
Hmm although the stdoutTTY part of that check also looks suspicious :raised_eyebrow: @imiric, you're the expert here, but shouldn't the if stdoutTTY be only around the logging of the warning?
Sorry @bbartizek, this version wasn't exhaustively tested on CI platforms and we haven't used CodeFresh before.
While we're working on a proper fix, you can work around this issue by forcing k6 to run in non-interactive mode, as suggested in #1580, e.g.: k6 run github.com/loadimpact/k6/samples/http_get.js 2>&1 | cat.
@na-- Far from expert :sweat_smile:, but yeah, that check should be more robust. I'll push a PR later today or on Monday.
@bbartizek, unless someone else comes forwards and reports the same issue on a more popular CI platform (and, if you're reading this and are having the same issue somewhere else, please write a comment here! :sweat_smile: ), or there's some other nasty bug in k6 v0.27.1, for now we don't plan to release v0.27.2 with only this fix cherry picked. Rather, this fix is likely going to be a part of k6 v0.28.0, which is slated for release mid-September (we're trying to move to 8-week release cycles).
Until then however, you'd still be able to use the new k6 features in CodeFresh, you'd just have to use the master docker image tag instead of latest. The price for that is some potential instability, even though we try to keep master stable.
@bbartizek, unless someone else comes forwards and reports the same issue on a more popular CI platform (and, if you're reading this and are having the same issue somewhere else, please write a comment here! 馃槄 ), or there's some other nasty bug in k6 v0.27.1, for now we don't plan to release v0.27.2 with only this fix cherry picked. Rather, this fix is likely going to be a part of k6 v0.28.0, which is slated for release mid-September (we're trying to move to 8-week release cycles).
Thanks for the update. I have no problem just running on 0.26.2 for now.
I am experiencing the same issue when piping the results to k6-to-junit
k6 run ./src/tests/test.js | k6-to-junit test.xml @imiric
@jeevananthank Are you running v0.27.1 in Codefresh? The panic is fixed on master, and will be part of v0.28.0 in a few weeks. In the meantime you can try building from master yourself.
EDIT: Sorry, it will be on master once #1581 is merged. Right now it's on the fix/1579-terminal-panic branch.
@imiric thanks for the quick reply. the issue is with k6 v0.27.1 in a windows machine (server 2019). the piping to k6-to-junit in azure devops pipelines works fine.
Hhmm can you post the full stracktrace here? The panic on Windows was with a specific terminal (Git Bash/mintty), and that was fixed in v0.27.1 (#1561). This issue is specific to Codefresh because of some terminal weirdness on that platform.
Maybe yours is a different issue, so please post the stacktrace, and the terminal you're using. And if you can, try compiling a Windows build from the fix/1579-terminal-panic branch. It should be as simple as GOOS=windows GOARCH=amd64 go build -o k6.exe if you have the Go toolchain setup.
I do not have Go setup to try the build right away, but am running the test from command prompt in admin mode
stack trace:
panic: runtime error: integer divide by zero
goroutine 7 [running]:
github.com/loadimpact/k6/cmd.renderMultipleBars(0x0, 0x7, 0x0, 0xffffffffffffffd8, 0xc00255c2d0, 0x2, 0x2, 0x0, 0xc000086060, 0xc001779950)
github.com/loadimpact/k6/cmd/ui.go:197 +0xdc0
github.com/loadimpact/k6/cmd.showProgress.func3(0xc003b13100)
github.com/loadimpact/k6/cmd/ui.go:292 +0x89
github.com/loadimpact/k6/cmd.showProgress(0x10ea700, 0xc001779940, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
github.com/loadimpact/k6/cmd/ui.go:330 +0x5c0
github.com/loadimpact/k6/cmd.glob..func11.1(0x10ea700, 0xc001779940, 0xc0005edc00, 0xc002f8c280, 0xc0000d6000, 0xc002fdf570)
github.com/loadimpact/k6/cmd/run.go:190 +0xc0
created by github.com/loadimpact/k6/cmd.glob..func11
github.com/loadimpact/k6/cmd/run.go:189 +0xb78
That seems like a slightly different stack trace, but it should be fixed by the changes in #1581.
What terminal are you using?
That seems like a slightly different stack trace, but it should be fixed by the changes in #1581.
What terminal are you using?
i used command prompt
@jeevananthank Thanks, I was able to reproduce your issue with piping to k6-to-junit, and could confirm that #1581 fixes that as well.
Sorry for this, I'm not aware of any workarounds for it. :( You can compile k6 from fix/1579-terminal-panic, or master hopefully soon, and the fix will be part of v0.28.0, scheduled for mid-September, or earlier in v0.27.2 if there are other urgent fixes.