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

lwip: Increase timeout on network tests with python projects #3832

Merged
merged 1 commit into from Mar 6, 2017

Conversation

geky
Copy link
Contributor

@geky geky commented Feb 23, 2017

Sometimes when under heavy load, the CI machines can take a significant amount of time to bring up a python process (~10s). The timeouts for the network tests were chosen without much thought, and didn't leave much room for this sort of delay.

This patch brings up timeouts for ntetwork tests 20s -> 60s

cc @bridadan

Sometimes when under heavy load, the CI machines can take a significant
amount of time to bring up a python process (~10s). The timeouts for
the network tests were chosen without much thought, and didn't leave
much room for this sort of delay.

This patch brings up timeouts for ntetwork tests 20s -> 60s
Copy link
Contributor

@teetak01 teetak01 left a comment

Choose a reason for hiding this comment

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

Would it not make sense to create some DEFAULT_TEST_TIMEOUT which could be used to fine-tune this kind of parameters? A few GENERIC parameters for groups of common tests.

@bridadan
Copy link
Contributor

I see your point, but I feel like that may obscure what the DEFAULT_TEST_TIMEOUT is. By reading the code you can at least see the timeout number and it isn't hidden behind a macro.

I like that your solution would reduce the amount of repeated code, but I have concerns it may cause more confusion. Just my opinion though!

@sg-
Copy link
Contributor

sg- commented Feb 23, 2017

/morph test-nightly

@bridadan
Copy link
Contributor

I ended up killing CI on this to let higher priority PRs get through testing first.

@mbed-bot
Copy link

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1698

Example Build failed!

@teetak01
Copy link
Contributor

Of course, it really depends how your tests work and how much similarity you can expect. We have some clearly-defined, often-used generic timeouts, like registration_timeout, rest_timeout, mock-timeout, etc.

@adbridge
Copy link
Contributor

adbridge commented Feb 24, 2017

Looks like nightly broke on the examples compilation:

mbed-os-example-mesh-minimal UBLOX_EVK_ODIN_W2 IAR failed

@bulislaw do you know if this example should pass with the ublox board ?

@bridadan
Copy link
Contributor

@adbridge I killed that build, it wasn't an actual failure.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 27, 2017

/morph test-nightly

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1602

All builds and test passed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants