* never try to write anything to the host's disks
* read as little as possible from the host's disks
* keep source in ram
* cache build artifacts and intermediate content persistently
Most of these hacks are only necessary because Docker disk performance on macOS is...not performant
Signed-off-by: Jesse Vincent <jesse@keyboard.io>
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
The workaround was put in place as an attempt to get virtual builds going on
macOS, natively. It wasn't enough, and it doesn't work, so lets drop it.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
We can pass arguments to the entrypoint from the `docker run` commandline, so we
do not need to do that via an environment variable. This way, we're an
environment variable and an `eval` shorter.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
To make it easier to reproduce things, and to help build in a clean environment,
this adds a thin Dockerfile that has Arduino and arduino-cli pre-installed, and
- along with the `bin/run-docker` script - is set up so that one can easily run
arbitrary commands in the context of the current bundle and Kaleidoscope.
The first run will take a while, because docker will build the image. Subsequent
runs will use the cache.
To use: `bin/run-docker make`, for example. Any argument passed to the
`bin/run-docker` will be eval-ed within the container, and will run there.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
In order to be able to access the devices as the at-seat user, without having to
fiddle with distro-specific permissions and groups, we need to tag it both
`uaccess` and `seat`, and have the rule sorted before the one that applies
permissions based on these tags. As such, the file had to be renamed as well.
Signed-off-by: Gergely Nagy <algernon@keyboard.io>
Jesse Vincent
Gergely Nagy