-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
tests: Increase some wait time in tests #6044
tests: Increase some wait time in tests #6044
Conversation
The bfd-bgp-cbit-topo3 test is testing bfd timers with some timers that only wait 4 seconds. The CI system is failing in various places due to bfd not converging properly. Upon logging into a CI system and running tests with intensive disk i/o I was able to make the tests fail repeatedly in a couple of different places. Add some additional time to allow the system to converge on our CI systems that are running in vm's and may not always have complete control of cpu's. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
💚 Basic BGPD CI results: SUCCESS, 0 tests failedResults table
For details, please contact louberger |
This change stopped a test failure:
|
I believe we'll need to watch this closely |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-11294/ This is a comment from an automated CI system. Warnings Generated during build:Debian 10 amd64 build: Successful with additional warningsDebian Package lintian failed for Debian 10 amd64 build:
|
The bfd-bgp-cbit-topo3 test is testing bfd timers
with some timers that only wait 4 seconds. The CI
system is failing in various places due to bfd
not converging properly. Upon logging into a
CI system and running tests with intensive disk i/o
I was able to make the tests fail repeatedly in
a couple of different places. Add some additional
time to allow the system to converge on our CI
systems that are running in vm's and may not
always have complete control of cpu's.
Signed-off-by: Donald Sharp sharpd@cumulusnetworks.com