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
If a VM-execution exceeds the timeout, iterations/repetitions are automatically reduced for the next VM-execution. But current VM-execution is marked as erroneous. This can be misleading if you don't get a hint, that it is "erroneous" because it exceeded the timeout. e.g. you just set two VMs to execute and each one is marked with error, you maybe will think there is a general problem.
Maybe just increasing timeout or reducing iterations/repetitions would solve your problem. Also you could set more VMs, so iterations/repetitions are reduced after the first executions and you get successful executions afterwards.
The message in case of automatically reduction should mention that, telling you that maybe the "error" is not really one and what you should try next.
Upstream changes
No response
The text was updated successfully, but these errors were encountered:
How should build-state be, if measurements give no results? Right now, e.g. if you set just 2 VMs and measurement-execution will exceed the timeout in each one, you will see 4 VM-runs marked with error. Build-state will be green in this case. This is ok, since no real error occurred. But you will not notice, that measurements did not produce results and that you should reconfigure (increasing VMs or timeout or decreasing repetitions/iterations directly). Maybe build-state should be unstable, if any test produces no measurement-results or even if configuration is changed, so that you will notice? (Should this be an extra issue?)
To solve this issue, two main steps need to be executed:
Saving the information, how iterations were reduced (in Peass)
Displaying them in Peass-CI
I'll take care of this in the next days.
Setting the build state to unstable would not be a good idea from my point of view, since is something that might happen (and that will happen frequently, if you just take a default configuration for all test cases). If you experience this issue frequently, I'd recommend to change the configuration.
What feature do you want to see added?
If a VM-execution exceeds the timeout, iterations/repetitions are automatically reduced for the next VM-execution. But current VM-execution is marked as erroneous. This can be misleading if you don't get a hint, that it is "erroneous" because it exceeded the timeout. e.g. you just set two VMs to execute and each one is marked with error, you maybe will think there is a general problem.
Maybe just increasing timeout or reducing iterations/repetitions would solve your problem. Also you could set more VMs, so iterations/repetitions are reduced after the first executions and you get successful executions afterwards.
The message in case of automatically reduction should mention that, telling you that maybe the "error" is not really one and what you should try next.
Upstream changes
No response
The text was updated successfully, but these errors were encountered: