-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Attempt to fix remoteload_test flakes and add better errors #4778
Conversation
@mightyguava: This PR has multiple commits, and the default merge method is: merge. Instructions 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. |
Hi @mightyguava. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mightyguava The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ref := "HEAD" | ||
if repoSpec.Ref != "" { | ||
ref = repoSpec.Ref | ||
} | ||
if err = r.run("fetch", "--depth=1", "origin", ref); err != nil { | ||
if err = r.run("fetch", "--depth=1", repoSpec.CloneSpec(), ref); err != nil { |
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.
Per git fetch docs,
The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL (see the section [GIT URLS](https://git-scm.com/docs/git-fetch#URLS) below) or the name of a remote (see the section [REMOTES](https://git-scm.com/docs/git-fetch#REMOTES) below).
As long as kustomize doesn't try to use origin
elsewhere in this cloned repo, and I don't believe it does, this change won't cause issues.
/ok-to-test |
t.SkipNow() | ||
} | ||
configureGitSSHCommand(t) | ||
testRemoteResource(req, test) | ||
testRemoteResource(t, test) |
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.
Thank you so much for fixing the sub-test fails parent test bug! I don't think this caused the flakes, but can we change test
to savedTest
here? This was also a bug I introduced.
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.
Ah I see. These tests don't run in parallel so it makes no difference. I removed the assignment to savedTest
in c6520a1
Closing in favor of #4783 |
Another step in #4640.
This PR attempts to address the flakes, but also adds better error messaging to debug the flakes if they aren't addressed.
Behavior Change
It adds better error messaging when remote loading fails. Instead of the previous error:
it will now show the output of the git command that failed as well, something like the below.
Test changes
271f393 changed all
assert
uses withrequire
to prevent panics. It also had the effect of short-circuiting table tests on error. The first failing test will skip all other tests. I changed somerequire
back toassert
so that they do not panic on error and allow all tests to run.All tests that load from remotes now either have
ref=v1.0.6
orsubmodules=0
, both of which will prevent submodules from being fetched. My suspicion is that this will not completely fix the flakes, but it should make them significantly less frequent. A few repeated CI runs will confirm.Results
I ran the test suite 100 times locally using the following command. They all passed, so I think the tests are no longer flaky.
CI Results
As can be seen from this build, tests are still flaky. Interestingly though, multiple tests failed on OS X but didn't fail on Linux. I think we don't want to disable these tests on the Mac build... so back to the drawing board.