You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using ember exam with the following flags--split=8 --parallel. Our CI pipeline was running for multiple hours because the ember exam step did not exit.
In the logs we noticed that one of the browsers exited:
Test Failure - Exam Partition 7 - TestLoader Failures: <some-test-file>: could not be loaded
Died on test #1 at Object.test (webpack://__ember_auto_import__/../../common/temp/node_modules/.pnpm/[email protected]/node_modules/qunit/qunit/qunit.js?:464:34): Could not find module `<some-source-file>` imported from `<some-test-file>`
However after this exit when the remaining partitions completed, this was logged:
.....Out of requested 8 browser(s), 7 browser(s) was launched & completed.
Waiting for remaining browsers to exited.
The process does not exit, ever. Regardless of the bug, I couldn't find any flags in the docs that would allow a max wait period to avoid such a situation?
The text was updated successfully, but these errors were encountered:
I'm unaware of such a flag and have a feeling like it might be connected more to testem than ember-exam, but that's just a guess 🤷♂️
I can only advise using built-in timeouts in CI services. CircleCI has a nice no_output_timeout flag which is low by default - 10 minutes without output and it terminates the job. GitHub actions' timeout on the other hand is designed to get money from you 😅 The default limit is high - 6 hours. So the first thing for GH Actions that I do is to set a low timeout 😉
We are using ember exam with the following flags
--split=8 --parallel
. Our CI pipeline was running for multiple hours because theember exam
step did not exit.In the logs we noticed that one of the browsers exited:
However after this exit when the remaining partitions completed, this was logged:
The process does not exit, ever. Regardless of the bug, I couldn't find any flags in the docs that would allow a max wait period to avoid such a situation?
The text was updated successfully, but these errors were encountered: