-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Remove happy tests #11373
Remove happy tests #11373
Conversation
PR #11373: Size comparison from 4947759 to 01ff8df Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
/rebase |
Rebasing to see if this works, failing a lot this weekend... |
01ff8df
to
70df612
Compare
PR #11373: Size comparison from 0c35285 to 70df612 Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
/rebase |
70df612
to
ecf4740
Compare
Fast track: this PR has been up while trying to figure out the reason for happy failures and it could not be resolved. PR does a pure deletion. |
ecf4740
to
fe0a74a
Compare
PR #11373: Size comparison from 4efa5de to fe0a74a Full report (21 builds for efr32, k32w, linux, p6, qpg, telink)
|
Is the functionality tested by happy already covered by cirque? |
Not as far as I am aware. It is a single test that validates 'multicast works with 5 nodes' from what I can tell. The problem I have with this test is that it seems to be quite flaky and the flake never uncovered any bugs. I am restarting builds several times a day due to this test and I see it causing more pain than value. |
PR #11373: Size comparison from e568d70 to 4ae5f11 Full report (26 builds for efr32, k32w, linux, mbed, p6, qpg, telink)
|
Removed fast track: had to iterate over it quite a bit and the dns tests may be a material change. For DNS tests, the state right now is that the tests will run on darwin and not on linux Feedback would be appreciated: @mspang @cecille @yunhanw-google @erjiaqing or other folks with experience with happy. |
PR #11373: Size comparison from e568d70 to c22f0e8 Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
PR #11373: Size comparison from 02d8a1a to 3793a07 Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
PR #11373: Size comparison from 4d341d4 to 621aac0 Full report (38 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
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.
I support removing the happy test as well.
Cirque is essentially a superset of happy, and we should just invest in that framework for such functional tests.
It's best to remove the happy dependency now when we only have 1 test using the framework than later when the cost is higher.
fast track: PR up for a while and had chats with people familiar with happy and now the PR has more checkmarks. |
Problem
Happy contains a single test (multicast) that is currently very flaky in CI, however I could not reproduce the error locally.
Since the happy platform seems to not be that used and we have alternatives (cirque for full end-to-end with multiple hosts), it seems easier to just remove the happy version instead of trying to debug the flakyness (I was unable to - we don't even seem to preserve debug log artifacts)
Happy seems to come with a lot of complexity (see that almost 3K lines deleted in this PR) for running a single test.
Change overview
Remove the happy test
Testing
CI validates this