You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While we the new remote execution workflows are very efficient, we are still running gigantic builds compared to most other projects. This means that we quickly fall out of the "free" or "open source" tiers of remote execution services. Self-hosting might be inevitable 😅
For a full setup there is buildfarm. Regarding remote caching there is the pretty good bazel-remote, but it might also be fun to try wrapping dragonflydb with the remote-api gRPC calls and use that as cache.
The remote-apis are fairly straightforward, so we could also build an entire stack ourselves.
The text was updated successfully, but these errors were encountered:
@SpamDoodler@JannisFengler@jaroeichler Being able to benchmark things like llvm/llvm-project#62269 is another case for us to roll our own remote execution servers. Slowing down development progress because of things like this things like this is annoying and unnecessary.
While we the new remote execution workflows are very efficient, we are still running gigantic builds compared to most other projects. This means that we quickly fall out of the "free" or "open source" tiers of remote execution services. Self-hosting might be inevitable 😅
For a full setup there is buildfarm. Regarding remote caching there is the pretty good bazel-remote, but it might also be fun to try wrapping dragonflydb with the remote-api gRPC calls and use that as cache.
The remote-apis are fairly straightforward, so we could also build an entire stack ourselves.
The text was updated successfully, but these errors were encountered: