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
cmd/cover: provide a mechanism to flush out coverage report #31007
Comments
/cc @alandonovan @rogpeppe @ianlancetaylor @jayconrod This seems like a clearly good thing to me - are there any disadvantages? I do wonder how this flushing mechanism would work, though, unless If we can more or less agree that this should happen, it would be great to get it into 1.13 and close all the related |
I like the idea, but what's the mechanism? |
Quoting Alan's comment which started this discussion:
Then Roger's comment:
So, I think a few clarifications should be made, if I'm understanding the original thread correctly:
Perhaps Alan can clarify, particularly since he didn't reply to Roger's comment. |
See also #30306. |
The function that does this currently is What happens if coverage data is still being recorded while that function is writing data out? Is the inconsistency okay? I don't think we currently have a global lock. |
Hi! I'm also interested on having a mechanism like this, for the same reasons (collecting coverage of binaries during integration tests, which sometimes have to exit with os.Exit(1)/log.Fatal). Are there any news on this? What's blocking the decision? Thanks! |
This comment was marked as duplicate.
This comment was marked as duplicate.
Change https://go.dev/cl/411907 mentions this issue: |
In some cases, such as golang.org/x/tools/go/analysis/singlechecker.Main, a function might need to call os.Exit/log.Fatal, but want to flush any coverage reports in progress before doing so.
This bug proposes providing a mechanism to flush out the coverage report, so that if there's one in progress, it can be flushed out.
The text was updated successfully, but these errors were encountered: