JVM languages can't share remote cache artifacts cross-platform

justhecuke-zz commented 4 years ago

Description of the problem / feature request:

Even though JVM languages that don't include native code can share artifacts cross-platform (theoretically) due to targeting the JVM and not the host/target/execution architecture, the command input/output paths used in the cache digest routinely the host/target/execution platform (e.g., darwin-fastbuild) into the path which means that we cannot share those JVM artifacts cross-platform.

Feature requests: what underlying problem are you trying to solve with this feature?

It would be great to be able to share those JVM artifacts cross-platform since they should be roughly interchangeable, especially Android artifacts.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Not a bug, but a feature request. However, you can quite easily reproduce this by building on a linux machine, upload to remote cache, then build on a darwin machine and note that you don't get any remote cache hits.

What operating system are you running Bazel on?

Darwin and linux (ubuntu)

What's the output of `bazel info release`?

release 3.2.0

If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.

N/A

What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

git@github.com:justhecuke/bazel_rules_detekt.git bffa68b4948aa26153185f4feda278557dc01951 bffa68b4948aa26153185f4feda278557dc01951

Have you found anything relevant by searching the web?

No, I found this data by building a custom bazel that output the command protos being used to generate action cache digests and noting the paths used and how they would prevent cross-platform sharing of JVM artifacts.

Any other information, logs, or outputs that you want to share?

No.

aiuto commented 4 years ago

You've identified a problem we are well aware of. We already have a long term project to improve this, with the deliverables named in different ways. So this is essentially a duplicate, but I can't, without searching, find the issues to dup against.

keith commented 4 years ago

@aiuto are there any public docs about the workstreams here? We might be interested in helping out if possible

justhecuke-zz commented 4 years ago

Any indication of what this long-term project is? I found https://github.com/bazelbuild/bazel/issues/8125 but that seems to be a subset of the work needed for this cross-platform reuse (if I read it right) because there are likely toolchain differences between macos and linux that would cause cross-platform re-use of JVM artifacts to fail anyways.

aiuto commented 4 years ago

This is a bit of work we can't easily invite others to.

The key element is to trim configuration fragments from targets when they can not matter to the end result. Your example of pure Java code with no deps on native code is a perfect example of that. The changes are an intertwined mix of (to start)

migrating rules to use platforms rather than explicit flags
changing the way we name output paths (https://docs.google.com/document/d/17snvmic26-QdGuwVw55Gl0oOufw9sCVuOAvHqGZJFr4/edit#heading=h.5mcn15i0e1ch)
refactoring configuration fragments
improving user defined transitions so more builds can be flagless

There is no single issue or quick fix. This is more of a known goal we are working towards and we use that goal as a way to evaluate changes and set priorities thoughout Bazel

artem-zinnatullin commented 4 years ago

Remote Execution should also allow different local host vs remote host for JVM and android_library/android_binary targets, ie running local build on macOS that connects to Remote Execution service backed by Linux machines.

blampe commented 4 years ago

So this is essentially a duplicate, but I can't, without searching, find the issues to dup against.

This might be related to #4714/#8339?

gregestren commented 1 year ago

We're expecting progress when the host/exec architecture is the same (like everyone's building on common Linux machines, targeting varying architectures). That's manageable with path stripping (bazel-out/x86-fastbuild/... -> /bazel-out/...).

If you also need caching across host/exec machines, that's an independent problem: there are legitimately different JDKs across architectures. We need to define equivalences for those. That's being looked at by a different group.

Feel free to ping here for more details. To be fair for everyone, it's probably best to close all bugs in this space and open one canonical one describing the whole problem, and who's doing what on it.

github-actions[bot] commented 7 months ago

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

bazelbuild / bazel