-
Notifications
You must be signed in to change notification settings - Fork 4.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
Distinguish the disk and remote caches in the action progress status. #20935
Conversation
cbc5f49
to
2388856
Compare
@@ -49,6 +49,11 @@ public DiskAndRemoteCacheClient(DiskCacheClient diskCache, RemoteCacheClient rem | |||
this.remoteCache = Preconditions.checkNotNull(remoteCache); | |||
} | |||
|
|||
@Override | |||
public String getDisplayName() { | |||
return "combined-cache"; |
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.
For combined cache, I would like it to first report disk-cache
and then remote-cache
if missed disk cache. Maybe we should move the event emission into the cache client?
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.
PTAL. (The architecture isn't great, but I don't see any better options.)
@bazel-io flag |
@bazel-io fork 7.1.0 |
Previously, they were both displayed as `remote-cache`; there's now a separate `disk-cache` form. If a combined cache is used, one or both forms will appear, depending on which caches were looked up. As a result, the progress status reporting is moved to the individual cache implementations. While this is kind of unfortunate from an architectural standpoint, it's likely the best we can do until we recast cache lookups as spawn strategies (see bazelbuild#19904). Closes bazelbuild#20935. PiperOrigin-RevId: 601748051 Change-Id: I03710219973c95d4fca999d931b3513f6d240d94
Previously, they were both displayed as `remote-cache`; there's now a separate `disk-cache` form. If a combined cache is used, one or both forms will appear, depending on which caches were looked up. As a result, the progress status reporting is moved to the individual cache implementations. While this is kind of unfortunate from an architectural standpoint, it's likely the best we can do until we recast cache lookups as spawn strategies (see bazelbuild#19904). Closes bazelbuild#20935. PiperOrigin-RevId: 601748051 Change-Id: I03710219973c95d4fca999d931b3513f6d240d94
… status. Previously, they were both displayed as `remote-cache`; there's now a separate `disk-cache` form. If a combined cache is used, one or both forms will appear, depending on which caches were looked up. As a result, the progress status reporting is moved to the individual cache implementations. While this is kind of unfortunate from an architectural standpoint, it's likely the best we can do until we recast cache lookups as spawn strategies (see bazelbuild#19904). Closes bazelbuild#20935. PiperOrigin-RevId: 601748051 Change-Id: I03710219973c95d4fca999d931b3513f6d240d94
… status. (#21084) Previously, they were both displayed as `remote-cache`; there's now a separate `disk-cache` form. If a combined cache is used, one or both forms will appear, depending on which caches were looked up. As a result, the progress status reporting is moved to the individual cache implementations. While this is kind of unfortunate from an architectural standpoint, it's likely the best we can do until we recast cache lookups as spawn strategies (see #19904). Closes #20935. PiperOrigin-RevId: 601748051 Change-Id: I03710219973c95d4fca999d931b3513f6d240d94
Previously, they were both displayed as
remote-cache
; there's now a separatedisk-cache
form. If a combined cache is used, one or both forms will appear, depending on which caches were looked up.As a result, the progress status reporting is moved to the individual cache implementations. While this is kind of unfortunate from an architectural standpoint, it's likely the best we can do until we recast cache lookups as spawn strategies (see #19904).