Conversation
1fdbd89 to
391be57
Compare
|
When implementing the (still unmerged) macOS backend, we seemed to have agreed on deciding the sandbox at build time. See question 3 here #87 (comment) and also #87 (comment). I don't know which approach would be best? |
|
sure, build-time is fine by me, I'll change it. It was just faster to implement it this way for the PoC |
8304c24 to
108ee76
Compare
Haha I just reimplemented the opposite: sandbox selection at runtime. I want to be able to use the Docker backend on Linux too, and now if you select the Docker store it will automatically select the docker "sandbox" too instead of runc. |
108ee76 to
91a5b70
Compare
That can always be implemented on top of build-time selection. You'd just have to list the available backends at build times instead of just one implementation. I think both are not exclusive with each other, and on my side it allows us to remove a dependency on extunix |
patricoferris
left a comment
There was a problem hiding this comment.
This looks great! I was wondering how you're testing it @kit-ty-kate, I could try a similar setup?
| | `Output -> Buffer.add_string buffer x | ||
|
|
||
| let healthcheck ?(timeout=30.0) t = | ||
| Os.with_pipe_from_child (fun ~r ~w -> |
There was a problem hiding this comment.
Should sandboxes each specify a "I have some system dependencies I need, let me check for them" function that we could call here? Or do you think the get_base + run_steps etc is sufficient?
|
|
||
| let fetch ~log ~rootfs base = | ||
| with_container ~log base (fun cid -> | ||
| let fetch ~log:_ ~rootfs base = |
There was a problem hiding this comment.
Have we lost the (* We might need to do a pull here, so log the output to show progress. *) by not doing anything with the log.
|
|
||
| let with_container manifest token fn = | ||
| Lwt_io.with_temp_dir ~perm:0o700 ~prefix:"obuilder-docker-hub-" @@ fun output_file -> | ||
| Docker_hub.fetch_rootfs ~output_file:(Fpath.v output_file) manifest token >>= |
There was a problem hiding this comment.
Converting to the docker-hub library seems sensible to me (presumably for FreeBSD support), the problem at the moment is that the means by which the tests mock lots of things is by hijacking the exec function that is used and catching calls to things like docker create.... Perhaps this code could be functorised over a docker_hub like thing ?
it's not working yet. I've only opened the PR to allow for some first-pass reviews. I've only just succeeded pushing a freebsd image to docker hub so far, i still haven't tried pulling it (i'm working on opam today) |
89e84ac to
ccd3f2f
Compare
|
FreeBSD support added in #174 |
Fixes #109
Requires kit-ty-kate/ocaml-docker-hub#1
TODO: