-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Remote execution is caching failed process #17142
Comments
So, we have a remedy for this, I think... but it's a little bit fiddly. We now explicitly wrap the The fiddly solution for this would be to set Whether that fiddly solution is worth it though is unclear. cc @tdyas , @illicitonion |
There's a separate field which I think is geared towards this use case - |
Ah, perfect! |
Fixed by #17188
I'm super confused why there was a cache hit in the first place. We are only supposed to write to the action cache if the exit code was 0, and the above logs clearly show the code was 1. We've never set Only possibility I can think of is if BuildGrid is directly writing to the ActionCache regardless of what we set ProcessCacheScope to be? pants/src/rust/engine/process_execution/src/remote_cache.rs Lines 501 to 508 in 15f662c
|
Remote execution systems will generally always write to the remote Action Cache. That is an expected part of how Remote Execution API works. |
Closes #17142. We rely on the RemoteCache command runner for caching with remote execution. We always disable remote servers from doing caching themselves not only to avoid wasted work, but more importantly because they do not have our same caching semantics, e.g. `ProcessCacheScope.SUCCESSFUL` vs `ProcessCacheScope.ALWAYS`.
The remote execution service I'm using is failing when running this process:
pants/src/python/pants/engine/internals/platform_rules.py
Lines 65 to 72 in 8cabd7d
I was confused that rerunning Pants did not result in anything being submitted to the RE servers. Turns out,
-ldebug
showed this:This was the case regardless of
--no-pansd
and--no-remote-cache-read
.I would expect that a) a failed process would not be cached, and b)
--remote-cache-read
should toggle the cache, generally.I worked around this by adding
ProcessCacheScope.PER_SESSION
, which guarantees a cache miss every run.The text was updated successfully, but these errors were encountered: