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

GoToolchainBinaryBuild leaves temp gopath dir (linux), or uploads to cache (windows) #3884

Closed
hauserx opened this issue Mar 10, 2024 · 1 comment · Fixed by #3885
Closed

Comments

@hauserx
Copy link
Contributor

hauserx commented Mar 10, 2024

What version of rules_go are you using?

0.46.0

What version of gazelle are you using?

0.35.0

What version of Bazel are you using?

6.4

What operating system and processor architecture are you using?

Linux & Windows

What did you do?

Build anything with rules_go.

What did you see instead?

Each GoToolchainBinaryBuild execution leaves 2 entries like /tmp/tmp.CGmiYEaaeP/ under linux. Those correspond to throwaway cache created by mktemp -d that is never cleaned up:
https://github.com/bazelbuild/rules_go/blob/d45e218910fbecb00867e3a4dde3fe14d4a1e00a/go/private/rules/binary.bzl#L462

Under Windows the same rule uses declare_directory to create space for cache and returns the declared directory from the rule, what causes uploading temporary gocache entries to remote cache and subsequent downloads.
https://github.com/bazelbuild/rules_go/blob/d45e218910fbecb00867e3a4dde3fe14d4a1e00a/go/private/rules/binary.bzl#L440

Cache contains ~500 files / 50MB, which are not really problematic numbers as those action usually do not execute often (maybe other than in CI), but still those temporary files should be cleaned up.

@fmeum
Copy link
Member

fmeum commented Mar 10, 2024

That assessment looks entirely correct.

Would you be interested in submitting a PR to fix one or both issues? Happy to review it!

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 a pull request may close this issue.

2 participants