studio/tuwunel
2
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

docker: Simplify build/install; dedup cargo commands; enable gc.

Browse Source 
Signed-off-by: Jason Volk <jason@zemos.net>
This commit is contained in:
Jason Volk
2025-06-03 19:00:00 +00:00
parent 71748c3db9
commit 55c35fc840
17 changed files with 66 additions and 227 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docker/README.md
View File

@@ -36,21 +36,7 @@ this step.
2. You will need to create a builder. There are a few complications that must be explained here
so please be patient.
1. Caches are being evicted in ways that I didn't expect, for example, rust is installed in a
cache mount which might have been a bad idea. I have disabled GC because an unlucky eviction
has massive repercussions. This is my buildkitd config in `~/.config/buildkit/buildkitd.toml`
```
[worker.oci]
enabled = true
rootless = true
gc = false
[system]
platformsCacheMaxAge = "504h"
```
2. Some unsavory options are required for some targets. It might be possible to omit these if
- Some unsavory options are required for some targets. It might be possible to omit these if
you're not building the full tree. Otherwise I've included them in the create command below.
- To run the complement compliance suite we need the `--allow-insecure-entitlement network.host`.
@@ -64,7 +50,6 @@ so please be patient.
--name owo \
--bootstrap \
--driver docker-container \
--buildkitd-config ~/.config/buildkit/buildkitd.toml \
--buildkitd-flags "$BKD_FLAGS"
```
@@ -96,34 +81,3 @@ choose `actor/repo/branch` with the expectation of one build at a time under tho
constraints. Some external caching might need to be contrived between builders for
deduplication but with care such that malicious actors cannot poison data used
by other actors, otherwise it defeats the purpose of builder isolation.
#### On Target Caches
The challenge here is to get all aspects of the target directory perfectly optimal
within the many constraints including cargo issues and our goals. This is highly complex
because we have to provide each image being built with a safe environment yet share as
much as possible between builds. This includes maximum reuse of prior builds but without
unnecessary dirtying or more serious unexpected conflicts.
We first create a hausdorff space based on builds which could never benefit from sharing
and would always be unsound (even silently) if they came into contact; so all cache id's
are prefixed by the matrix components:
`${sys_name}/${sys_version}/${rust_target}/${rust_toolchain}/${cargo_profile}`. This is
important because we can simplify the mount path inside the image which is important for
the absolute paths generated by fingerprints and dependency files. We need to keep those
the same if any builds expect to share them.
The top-level of target directory is immediately partitioned by cargo into different
profiles. Note that we already imposed separation based on profile but we still have to
deal with that subdirectory in the mount, which has special-cases for the dev, test, and
bench profiles. These directories at their top-level are the final artifact area which is
not concurrency safe and there are open issues in cargo for explicit artifact directories.
Within these unsafe directories are sub-directories which contain hash-sharded components
making them safe again for shared caching, so long as the path to them remains consistent
for all images mounting.
As you can see this is already getting very complicated. If this is done wrong lots of
different bad things can happen such as broken builds from bad conflicts, constant
rebuilds from modest conflicts, or over-use of resources from too much separation.
TODO