https://github.com/rrbutani/bzlcon24-demo

PoC for https://github.com/rrbutani/bazel (see: https://github.com/rrbutani/bzlcon24-slides)
https://github.com/rrbutani/bzlcon24-demo

Last synced: about 2 months ago
JSON representation

PoC for https://github.com/rrbutani/bazel (see: https://github.com/rrbutani/bzlcon24-slides)

• Host: GitHub
• URL: https://github.com/rrbutani/bzlcon24-demo
• Owner: rrbutani
• Created: 2024-10-14T04:15:48.000Z (2 months ago)
• Default Branch: main
• Last Pushed: 2024-10-15T23:20:46.000Z (2 months ago)
• Last Synced: 2024-10-17T12:32:02.230Z (2 months ago)
• Language: Starlark
• Size: 42 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        

# Extended Bazel Linux Sandbox Demo

## what

...

## how do i run this?

> [!NOTE]

> This repo demonstrates the use of the [extended Bazel linux sandbox](TODO: fork link, talk link) to describe all "host system" dependencies.

>

> In doing do we end up talking about system specific details and paths (i.e. of shared objects) — while it's possible to model these details in a system agnostic way in Bazel (i.e. by using repository rules that do auto-detection) for the sake of this example, for simplicity, we use a [Docker container](./Dockerfile) to define a common system environment.

>

> This repo also cuts some concerns when it comes to modeling host dependencies in a composable way — in reality we'd like to use toolchains for this but for simplicity this demo does not do so.

> [!IMPORTANT]

> This repo only works with x86_64 Linux — in theory adapting what's here to other architectures (aarch64, armv7, riscv64) should be straight-forward but it has not been attempted.

> [!WARNING]

> Privileges are required (see [here](https://man7.org/linux/man-pages/man7/capabilities.7.html) and [here](https://man7.org/linux/man-pages/man7/user_namespaces.7.html)) [^caveat] in order to use Bazel's linux sandbox within Docker (allows us to create user namespaces within an existing user namespace); at run time we pass `--privileged`, at container build time we do not use the linux sandbox.

```console

❯ docker build \

    ${https_proxy+--build-arg HTTPS_PROXY="$https_proxy"} \

    -t bzl-sandbox-demo - < Dockerfile

```

[^caveat]: unfortunately scoping down the permissions to `-cap-add=SYS_ADMIN --cap-add=CAP_SYS_CHROOT` isn't sufficient — still yields permission errors for `mount`, have not investigated..

```console

❯ docker run \

    --privileged \

    -v "$(pwd)":/workarea \

    ${https_proxy+--env HTTPS_PROXY="$https_proxy"} \

    --tmpfs /tmp:exec \

    -it bzl-sandbox-demo bash

```