-
Notifications
You must be signed in to change notification settings - Fork 1.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
ci: Out of the tarpit #2923
Merged
Merged
ci: Out of the tarpit #2923
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes nil pointer issue in staticcheck
MarcoPolo
force-pushed
the
marco/out-of-the-tarpit
branch
from
August 16, 2024 18:30
40ad7a2
to
5f96d50
Compare
sukunrt
approved these changes
Aug 20, 2024
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.
Can't wait to start using this ❤️
sukunrt
pushed a commit
that referenced
this pull request
Aug 30, 2024
* Lint fixes * Use latest go version for go-check Fixes nil pointer issue in staticcheck * Add test_analysis helper script * Use custom go-test-template * Add some tests to the test_analysis script * Always upload test_results db * Attempt to fix test on windows * Better if statement * Try to fix flaky test * Disable caching setup-go on Windows * Better if statement * Tweak * Always upload summary and artifact * Close db * No extra newline
MarcoPolo
added a commit
that referenced
this pull request
Sep 4, 2024
* Lint fixes * Use latest go version for go-check Fixes nil pointer issue in staticcheck * Add test_analysis helper script * Use custom go-test-template * Add some tests to the test_analysis script * Always upload test_results db * Attempt to fix test on windows * Better if statement * Try to fix flaky test * Disable caching setup-go on Windows * Better if statement * Tweak * Always upload summary and artifact * Close db * No extra newline
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR gets us out of the tarpit of flaky tests. It reruns failed tests to see if they are flaky. If they consistently fail, the job fails. If they are flaky, they are recorded as such, but the job succeeds. The job outputs a sqlite database of all test runs. The table includes information on whether the test passed or failed and how many times for each.
The summary now includes what specific test failed, so you don't have to hunt through the logs to see what failed. It will also link you to an observable dashboard that lets you dive deeper. example
I think it's worth experimenting with this, and we can always revert it later.
Some valid concerns:
Q: Why do this?
A: Making changes has been feeling like walking through a tarpit with regard to CI. And a bad CI desensitizes you to actual failures. CI failures should be very high signal and very low noise.
Q: Won't this hide flaky tests?
A: No more than we are already doing by rerunning the tests. I'd even argue it hides it less because all the flakiness is presented on a single page rather than spread out across runs.
Q: What happens when a test is so flaky it fails everytime?
A: Sounds like an easy test to fix. Most, if not all, of our flakes happen less than 20%.
Q: Does this replace the Flaky Tests dashboard?
A: Not yet. Although I have a FlakyTestsV2 dashboard that makes better use of the sqlite format. This method is much easier to iterate on and much faster than the original Flaky Tests Dashboard.
Q: Why are you "forking" go-test-template.yml?
A: There's no other way of doing the changes I want to do. I think go-libp2p can graduate to owning its own
go-test
workflow. I prefer the simple workflow calling composite actions strategy to the shared reusable workflow across many projects. For now, the changes are minimal between the in-tree go-test-template.yml and the upstream one. In the future I may remove even more things from it.This PR isn't intended to be the final state. I'd like to clean up the summaries and dashboard a lot more. But I do think this current branch is a lot better than what we have.
How it works:
It introduces a
go test
helper script that:go test ./...
n
more times.There's also an Observable dashboard that: