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

Skip slow tests on Travis #12697

Closed
wants to merge 1 commit into from
Closed

Conversation

bukka
Copy link
Member

@bukka bukka commented Nov 17, 2023

Travis jobs often fails due to not completing in 50 minutes. When it's successful, it's very close to 50 minutes so we need to do something about reducing the time of tests of travis. The most effective option should be to skip all slow tests which is probably fine on travis as it's just for s390x arch which is primarily to test a big endian so missing out on few slow tests should be hopefully fine...

@bukka bukka changed the base branch from master to PHP-8.2 November 17, 2023 10:58
@iluuu1994
Copy link
Member

iluuu1994 commented Nov 17, 2023

Hmm, these tests started failing on master on Travis a while ago. #10738 I'm not familiar with gz so I never figured out the cause.

@bukka
Copy link
Member Author

bukka commented Nov 17, 2023

shouldn't you put XFAIL on them rather than SKIP...

@bukka
Copy link
Member Author

bukka commented Nov 17, 2023

I will merge this as it just surfaced an issue but at least it now runs all tests.

@iluuu1994
Copy link
Member

@bukka XFAIL is fine, it's just kinda useless (as it wastes CI time but doesn't really add anything).

@bukka bukka closed this in 708e9fa Nov 17, 2023
@bukka
Copy link
Member Author

bukka commented Nov 17, 2023

yeah but it marks test as having potentially issue that might need to be investigated. But I see that you also created an issue for that so it's fine

@iluuu1994
Copy link
Member

iluuu1994 commented Nov 17, 2023

Right. It would be more useful if CI failed if XFAIL succeeds, as it only warns and people rarely look at the CI output of succeeded jobs it's not very helpful. This would require writing more precise SKIPIF sections, but that would likely be a good thing.

@bukka
Copy link
Member Author

bukka commented Nov 17, 2023

Some XFAIL tests are actually flaky which I think is ok because one might not need to spend too much time to investigate XFAIL. I think the useful think about XFAIL is that it's listed in CI output compare to skip ones. So if something is skipped, it will more likely get forgotten. But if there's also GH issue which is ideal case, then it's fine I think.

@iluuu1994
Copy link
Member

I don't think XFAIL is a good solution for flaky tests, specifically because XFAIL emits a warning. If a bunch of tests warn, that makes it even less likely that a "previously failing, now passing" XFAIL test is discovered. I know added the FLAKY section which repeats the test if it fails.

I think the useful think about XFAIL is that it's listed in CI output compare to skip ones.

Yes, user indication is arguably the best part about xfail.

ramsey pushed a commit that referenced this pull request Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants