-
Notifications
You must be signed in to change notification settings - Fork 8
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
Consider building our own remote execution service #91
Labels
enhancement
New feature or request
Comments
turbo-cache might be interesting for us. |
@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. |
After the migration to LRE and the introduction of the NativeLink infrastructure this is no longer necessary. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: