Skip to content
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

Integrate bazel remote cache server with the bazel build POC #74105

Closed
mistic opened this issue Aug 3, 2020 · 6 comments
Closed

Integrate bazel remote cache server with the bazel build POC #74105

mistic opened this issue Aug 3, 2020 · 6 comments
Assignees
Labels

Comments

@mistic
Copy link
Member

mistic commented Aug 3, 2020

After setting up the kbn packages to build with bazel (#74104) we should experiment to integrate it with a remote cache server.

@mistic mistic added chore Team:Operations Team label for Operations Team build investigating labels Aug 3, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-operations (Team:Operations)

@mistic mistic mentioned this issue Aug 3, 2020
23 tasks
@mistic mistic self-assigned this Aug 3, 2020
@joshdover
Copy link
Contributor

joshdover commented Aug 12, 2020

I've been thinking about this some more and while I'm really excited about Bazel in the long-term, I'm wondering if we should do something really simple in the short term for the @kbn/optimizer in development.

We already have cache keys produced by @kbn/optimizer so I wonder if we should go ahead and setup a really basic blob store that the optimizer can lookup pre-built assets from. I think the biggest hurdle would be figuring out how to do this in a safe way so that only trusted machines are allowed to write to the cache (maybe only CI?), but otherwise it may be simple enough to setup a storage bucket in GCP.

It could work something like:

  • Take our existing cache key (which is a JSON doc), and produce a hash with sha256
  • See if an object with that key exists in the cache:
    GET https://storage.googleapis.com/storage/v1/b/kibana-dev-optimizer-cache/o/<sha256hash>.zip
    
  • If it exists, download and extract all the bundles for that plugin into it's target/public directory
  • If not, build the plugin

In CI, we would have the appropriate credentials for putting new items into the cache.

cc @spalger

@spalger
Copy link
Contributor

spalger commented Aug 12, 2020

It's definitely something I've suggested to folks before, I don't think it would be that hard to build, but I haven't seen any interest before now in a feature that will likely rely on some infrastructure to get right.

Converting the cache key to make sure that it is totally reproducible and not reliant on the OS or repo location would be the first step.

@joshdover
Copy link
Contributor

I think we're getting to the point where we've squeezed what we can out of the optimizer and other than removing legacy plugin discovery, I'm not sure there's a lot of low hanging fruit left to improve the start up time of Kibana when switching branches.

Could be a really good Spacetime project that would have a big impact.

@tylersmalley
Copy link
Contributor

I agree that this could be a big win if we get the cache key right.

@spalger, would you mind creating an issue to track adding remote caching to kbn/optimizer and include any changes you see us needed in terms of generating a cache key? I would rather we move the discussion there than take over this one related to Bazel and the packages POC.

@mistic
Copy link
Member Author

mistic commented Sep 1, 2020

I think at this point in the context of the POC we already did a lot of tests with the remote cache server. More info could be found on #69706 (comment) in the Remote Cache section

@mistic mistic changed the title Integrate bazel remote cache server with the bazel build poc Integrate bazel remote cache server with the bazel build POC Oct 1, 2020
@mistic mistic closed this as completed Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants