-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix incorrect test setup order in cgroups bats test. #5596
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
Conversation
ebb0aa1 to
faceaf3
Compare
|
/approve LGTM, thanks @klihub ! @cri-o/cri-o-maintainers PTAL |
faceaf3 to
65ab94b
Compare
Codecov Report
@@ Coverage Diff @@
## main #5596 +/- ##
==========================================
+ Coverage 43.07% 43.18% +0.10%
==========================================
Files 123 123
Lines 12295 12267 -28
==========================================
+ Hits 5296 5297 +1
+ Misses 6491 6462 -29
Partials 508 508 |
65ab94b to
acc76a6
Compare
fgiudici
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klihub , nice catch, thank you!
Overall LGTM.
Seems to me the check-bats-setup.sh script will just check that the first occurrence of setup_test comes before the first usage of TESTDIR in the file. That may help, but will not check if this is true for all the tests: it will work only in the bats file where the setup_test is in the function_setup() (which honestly is always the case but for the apparmor.bats file). While this doesn't harm and may just help, having a more generic check may be a better option.
edb8f03 to
076a7ff
Compare
|
/retest |
1 similar comment
|
/retest |
4d46651 to
4ef37af
Compare
fgiudici
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @klihub , the changes lgtm!
I found few places where we do double checks if the vars are set, but didn't spot any missing one, thank you!
4ef37af to
f345107
Compare
|
thanks for working through this @klihub |
|
@klihub have you found where in CI we still have old bats? |
@kolyshkin At least these are running older versions:
I suspect ci/openshift-jenkins/integration_rhel is the same, but looks like this time it failed earlier so the corresponding logs were not collected. |
b66ebac to
f8ad0b4
Compare
@kolyshkin Looks like the real problematic ones run the really bad combination of CentOS-7 using |
f8ad0b4 to
7a567b1
Compare
|
/test e2e_features_fedora |
7a567b1 to
9527d78
Compare
|
/hold |
9527d78 to
66f01e5
Compare
@kolyshkin Rebased on latest |
203a347 to
0728485
Compare
Don't dereference $TESTDATA before the test case is set up. Signed-off-by: Krisztian Litkey <[email protected]>
Run tests with 'set -u' treating any substitution of unset variables (other than $* and $@) as errors. Try to fix all existing test cases to adhere to this strict shell behavior. Signed-off-by: Krisztian Litkey <[email protected]>
1855da9 to
b6387cc
Compare
|
@klihub: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
This has been split up to multiple PRs and merged piecemeal. I think everything present here has been covered by those. Closing this accordingly... |
Fix a number of problems related to CI tests. Huge thanks to @haircommander in helping me narrow down the test setup ordering problem:
set -u)What type of PR is this?
/kind failing-test
What this PR does / why we need it:
An incorrect order of calling
setup_testand evaluating$TESTDIRcauses cgroups test cases to share supposedly private test files and random test failures. This typically manifests itself as a conflict between thectr with swap should be configuredandctr with swap should fail when swap is lowertests, with either one failing with a seemingly impossible condition. In reality this is caused by one of those test cases overwriting the container configuration input file generated by the other, before that file could be taken into use by the failing test case.Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Does this PR introduce a user-facing change?