bazel: 0.22.0 doesn't build in Darwin sandbox

[groodt]

Motivation for this change

There have been a number of attempts to include new versions of Bazel in nixpkgs, built on top of the existing derivation for 0.22.0.

See:
#58147
#58116
#56587

All of these attempts have stalled because Ofborg builds for Darwin time out and local sandbox builds fail.

Local failure:

no configure script, doing nothing
building
mkdir: cannot create directory '/tmp/.bazel-501': Operation not permitted
builder for '/nix/store/l13iplvdf344kadkd7iqbci65kxly8vz-bazel-0.22.0.drv' failed with exit code 1
error: build of '/nix/store/l13iplvdf344kadkd7iqbci65kxly8vz-bazel-0.22.0.drv' failed

This PR is intended to demonstrate that the 0.22.0 version suffers from the same sandboxing problems and that the currently published 0.22.0 version of Bazel was published with sandboxing disabled.

To me this indicates that something has changed with Darwin sandboxing on Ofborg to make it more restrictive (and correct) than it was previously. Or, somehow the existing Bazel 0.22.0 on Hydra was published with sandboxing disabled. It doesn't really matter what happened, but it raises an interesting question: What now?

The Bazel 0.22.0 build is not reproducible under sandboxing and future versions of Bazel are unlikely to build with sandbox = true on Darwin unless something significant happens with a JDK version that can execute inside the sandbox.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[groodt]

@Profpatsch When you get a moment, please trigger a Hydra build of this.

I'm curious to see what happens, but my suspicion is that it will fail under sandboxing because export TMPDIR=/tmp/.bazel-$UID is not permitted inside the sandbox.

[etu]

@GrahamcOfBorg build bazel

Not sure why this commit would do anything what so ever, but if you think it will help you to debug something... I'll trigger it for you.

[groodt]

Not sure why this commit would do anything what so ever, but if you think it will help you to debug something... I'll trigger it for you.

@etu Yes, I know it's weird! I've been having a very tough time trying to update this derivation. Current thinking is that something has changed in Hydra and that this build will now fail on Darwin. I simply changed the hash of the derivation so that it builds again.

If this builds successfully, then I really am stumped, because it shouldn't work according to my understanding, but somehow, it's green and cached on master.

[groodt]

As suspected, this derivation now fails on Hydra for Darwin, even though nothing in the derivation has changed that would cause it to fail:
https://github.com/NixOS/nixpkgs/pull/58557/checks?check_run_id=88804307

It fails with the same timeout issue as the attempts at upgrading Bazel to 0.23.x and 0.24.0.

cc @uri-canva @Profpatsch

[groodt]

Just fyi @LnL7

If you are looking for a build where a Darwin sandbox error results in a Timeout with Ofborg.

[groodt]

Closing. This was a misunderstanding. It is known that Ofborg Darwin builds can fail if sandboxing is enabled. Hydra Darwin builds do not enable sandboxing, so Ofborg failures in these scenarios can be ignored if the derivation builds locally and confirmed working on an OSX machine.