I guess to all just anyone to write to the cache, ...
# development
f
I guess to all just anyone to write to the cache, that would take some notion of cache scopes right? Like you'd perhaps have a cache scope per branch, so at best someone on that branch could poison only their own caches. Main branch runs could have global scope. I have no idea how to implement this, but it seems like something like this would be useful as a feature in Pants, and not just something we set up for the Pants CI itself
f
For the REAPI-based remote cache?
f
Yeah. I suppose we're dependent on using info available in REAPI...
f
My point is that cache scope is somewhat not an issue if you are talking about REAPI. It is a content-addressable storage and the cache key is the SHA-256 digest of the relevant Action/Command protobufs.
It matters from a security standpoint if there are users who should not share an Action Cache, but that's not the case here because pants maintainers sharing the cache should be fine.
But sharing branches with same cache is fine since the sources passed into
Process
are part of the cache key since the input root digest is part of the Action proto, and so part of the SHA-256 digest. Merkle tree and all that.
b
I suspect the original question might be about allowing forked non-maintainer PRs to write to a cache too? (This kind of cache scoping is exactly how GHA's cache works: everything can read from the main branch's cache, but writes are scoped per branch.)
f
yeah, if it is forked non-maintainer PRs at issue, than that implicates the security point since you may not want to expose write access to the Action Cache to them.
if there were some sort of REAPI proxy which can allow fallback to another cache level, maybe that could work
if I were still at Toolchain, that would have been straightforward to implement in Toolchain's REAPI cache service
BuildBarn might be flexible enough to allow something like that to be configured.
I'd also check TurboCache https://github.com/allada/turbo-cache
f
I suspect the original question might be about allowing forked non-maintainer PRs to write to a cache too?
Yes. And about allowing forks in general