-
Notifications
You must be signed in to change notification settings - Fork 18
Add support for FreeBSD #120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: