Thanks for your interest in contributing! At the current time, bootc is implemented in Rust, and calls out to important components which are written in Go (e.g. https://github.com/containers/image) as well as C (e.g. https://github.com/ostreedev/ostree/). Depending on what area you want to work on, you'll need to be familiar with the relevant language.
There isn't a single approach to working on bootc; however the primary developers tend to use Linux host systems, and test in Linux VMs. One specifically recommended approach is to use toolbox to create a containerized development environment (it's possible, though not necessary to create the toolbox dev environment using a bootc image as well).
At the current time most upstream developers use a Fedora derivative as a base, and the hack/Containerfile defaults to Fedora. However, bootc itself is not intended to strongly tie to a particular OS or distribution, and patches to handle others are gratefully accepted!
- A development environment (toolbox or a host) with a Rust and C compiler, etc. While this isn't specific to bootc, you will find the experience of working on Rust is greatly aided with use of e.g. rust-analyzer.
- An installation of podman-bootc which note on Linux requires that you set up "podman machine".
Worth stating: before you start diving into the code you should understand using the system as a user and how it works. See the user documentation for that.
Edit the source code; a simple thing to do is add e.g.
eprintln!("hello world); into run_from_opt in lib/src/cli.rs.
You can run make or cargo build to build that locally. However, a key
next step is to get that binary into a bootc container image.
Use e.g. podman build -t localhost/bootc -f hack/Containerfile ..
From there, you can create and spawn a VM from that container image with your modified bootc code in exactly the same way as a systems operator would test their own bootc images:
$ podman-bootc run localhost/bootc
You don't need to create a whole new VM for each change, of course. containers/podman-bootc#36 is an outstanding PR to add virtiofsd support, which would allow easily accessing the locally-built binaries. Another avenue we'll likely investigate is supporting podman-bootc accessing the container images which currently live in the podman-machine VM, or having a local registry which frontends the built container images.
A simple hack though (assuming your development environment is compatible
with the target container host) is to just run a webserver on the host, e.g.
python3 -m http.server or whatever, and then from the podman-bootc guest
run bootc usroverlay once, and
curl -L -o /usr/bin/bootc http://10.0.1.2:8080/target/release/bootc && restorecon /usr/bin/bootc.
The hack/lldb directory contains an example of how to use lldb to debug bootc code.
hack/lldb/deploy.sh can be used to build and deploy a bootc VM in libvirt with an lldb-server
running as a systemd service. Depending on your editor, you can then connect to the lldb server
to use an interactive debugger, and set up the editor to build and push the new binary to the VM.
hack/lldb/dap-example-vim.lua is an example for neovim.
The VM can be connected to via ssh test@bootc-lldb if you have nss
enabled.
For some bootc install commands, it's simpler to run the lldb-server in a container, e.g.
sudo podman run --pid=host --network=host --privileged --security-opt label=type:unconfined_t -v /var/lib/containers:/var/lib/containers -v /dev:/dev -v .:/output localhost/bootc-lldb lldb-server platform --listen "*:1234" --serverFirst, you can run many unit tests with cargo test.
There's a small set of tests which are designed to run inside a bootc container and are built into the default container image:
$ podman run --rm -ti localhost/bootc bootc-integration-tests container