Various upgrades, Scala 3, multiplex sandboxing, path mapping #85
Conversation
.bazelrc_shared
Outdated
| @@ -8,20 +8,13 @@ build --tool_java_runtime_version="remotejdk_21" | |||
| # Other options | |||
| build --experimental_use_hermetic_linux_sandbox | |||
| build --experimental_worker_sandbox_hardening | |||
| build --experimental_worker_multiplex_sandboxing | |||
There was a problem hiding this comment.
Super-nit but would you mind re-sorting these? I'm trying to keep our Bazel options organized.
.github/workflows/ci.yml
Outdated
| @@ -14,7 +14,7 @@ jobs: | |||
| fail-fast: false | |||
| matrix: | |||
| os: [ubuntu-24.04] | |||
| bazel_version: [bazelbuild/8.1.0] | |||
| bazel_version: [bazelbuild/8.1.1] | |||
There was a problem hiding this comment.
Won't we need CI to be on our custom version of Bazel, since that's the environment in which the bug is occurring?
There was a problem hiding this comment.
It should still use the version in Bazelisk. I believe this is just the version it sets up initially. Otherwise the CI builds wouldn't have passed when using the custom bazel version + multiplex sandboxing.
There was a problem hiding this comment.
But good point, I'll try to update this
There was a problem hiding this comment.
I believe this is just the version it sets up initially.
I'm not sure if you've answered this question before, but do you know why it has to set up an initial version at all? If we can just have it install Bazelisk, we won't need to update this and the builds will run faster.
There was a problem hiding this comment.
I agree. I honestly haven't looked at this deeply, so it's possible this isn't really doing anything.
This requires a custom version of Bazel until the fix is merged, so we're on 8.1.1 + the fix for multiplex sandboxing.
Some of the code we produce gets used as libraries by other rule sets, so we should prefer the LTS over the Next branch.
8e5a2c8 to
8920ddf
Compare
No description provided.