Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit the number of test steps/results that can be created #2322

Merged
merged 2 commits into from Jun 9, 2023

Conversation

Martchus
Copy link
Contributor

@Martchus Martchus commented Jun 6, 2023

@codecov
Copy link

codecov bot commented Jun 6, 2023

Codecov Report

Merging #2322 (ff2ab7c) into master (f1fcf99) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #2322   +/-   ##
=======================================
  Coverage   94.97%   94.98%           
=======================================
  Files         155      155           
  Lines       15189    15216   +27     
=======================================
+ Hits        14426    14453   +27     
  Misses        763      763           
Impacted Files Coverage Δ
basetest.pm 99.40% <100.00%> (+0.01%) ⬆️
t/17-basetest.t 100.00% <100.00%> (ø)

@Martchus
Copy link
Contributor Author

Martchus commented Jun 6, 2023

This results in a test failure (not incomplete) with

[2023-06-06T16:14:52.417984+02:00] [debug] [pid:19304] Maximum allowed test steps (MAX_TEST_STEPS=10000) exceeded, aborting at /hdd/openqa-devel/repos/os-autoinst/basetest.pm line 415.

followed by a backtrace.

Not the nicest outcome but I guess acceptable. I'm not even sure whether we should consider this an incomplete because this actually is a test mistake (test produces too many results).

In my local test I've noticed that the limit of 10000 is actually nothing. The web UI can still handle it quite well and it doesn't look that huge. In fact, I'm afraid we'd run into that limit in production jobs and would fail those jobs quite needlessly. So I'll do some more local testing to determine a more sensible limit.

My findings so far:

  • 10 000 is still not problematic
  • 50 000 already takes very long to upload but loading the page also is a bit problematic
  • 100 000 is way too much

kalikiana
kalikiana previously approved these changes Jun 6, 2023
@kalikiana kalikiana dismissed their stale review June 6, 2023 15:41

not ready

@okurz
Copy link
Member

okurz commented Jun 6, 2023

This results in a test failure (not incomplete) […]
Not the nicest outcome but I guess acceptable. I'm not even sure whether we should consider this an incomplete because this actually is a test mistake (test produces too many results).

I would favor "incomplete". When we implemented the "reason" (mostly you did, of course) we decided that incomplete with specific reasons is fine even if the instance admins are not the right target audience but test maintainers. Think of examples like "missing asset", "unable to find schedule file", etc. So can it be made an "incomplete"?

In my local test I've noticed that the limit of 10000 is actually nothing. The web UI can still handle it quite well and it doesn't look that huge. In fact, I'm afraid we'd run into that limit in production jobs and would fail those jobs quite needlessly. So I'll do some more local testing to determine a more sensible limit.

My findings so far:

* 10 000 is still not problematic
* 100 000 is way too much

good point. I would be ok with anything in the range 10k-100k as a default :)

@Martchus
Copy link
Contributor Author

Martchus commented Jun 6, 2023

So can it be made an "incomplete"?

Ok, I suppose that makes sense. And the answer to the question is of course yet. Then a simple "die" doesn't suffice anymore of course.

I'm currently trying 50000 and I guess it is still too big. I guess I'll have to do at least one more test tomorrow. I suppose it is actually on the edge of what makes sense. So maybe 50000 is a good limit. 25000 is still displayable well enough although the upload already takes way too long.

@Martchus
Copy link
Contributor Author

Martchus commented Jun 7, 2023

I've just changed the limit to 50000 which is hopefully high enough to still cover valid production use cases and low enough to now crash the browser for most users (likely depends on the available RAM). Since finding a sensible limit that fits all use cases is likely not possible it is good that this can still be changed via the job setting MAX_TEST_STEPS. On that note I'd say it is also supposedly ok to not enforce anything on the server-side after all.

@Martchus Martchus removed the not-ready label Jun 7, 2023
A worker change is required for passing the "incomplete" result
to the web UI. Otherwise the job just ends up "failed" (still
with the proper reason).

Related ticket: https://progress.opensuse.org/issues/129068
@okurz
Copy link
Member

okurz commented Jun 9, 2023

I retriggered GHA CI jobs which passed now but we are missing codecov check results even though there is a coverage message comment. Trying rebasing.

@Mergifyio rebase

@mergify mergify bot merged commit 71f4f99 into os-autoinst:master Jun 9, 2023
15 checks passed
@okurz
Copy link
Member

okurz commented Jun 9, 2023

huh, seems like mergify was just slower than I expected :D All good

@@ -399,15 +412,21 @@ sub save_test_result ($self) {
return $result;
}

sub _increment_test_count ($self, $max = $bmwqemu::vars{MAX_TEST_STEPS} // 50) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that should be 50000 and not 50? Or am I missing something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like a problem in rebasing happened here. I will create a fix

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in #2323

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed by #2323

@Martchus Martchus deleted the limit-steps branch June 9, 2023 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants