@@ -34,47 +34,68 @@ accepted!
3434- A development environment (toolbox or a host) with a Rust and C compiler, etc.
3535 While this isn't specific to bootc, you will find the experience of working on Rust
3636 is greatly aided with use of e.g. [ rust-analyzer] ( https://github.com/rust-lang/rust-analyzer/ ) .
37- - An installation of [ podman-bootc] ( https://github.com/containers/podman-bootc-cli )
38- which note on Linux requires that you set up "podman machine". This document
39- assumes you have the environment variable ` CONTAINER_CONNECTION ` set to your
40- podman machine's name.
37+ - Install [ bcvk] ( https://github.com/bootc-dev/bcvk ) .
4138
4239## Ensure you're familiar with a bootc system
4340
4441Worth stating: before you start diving into the code you should understand using
4542the system as a user and how it works. See the user documentation for that.
4643
47- ## Creating your edit-compile-debug cycle
44+ ## Understanding the Justfile
4845
4946Edit the source code; a simple thing to do is add e.g.
50- ` eprintln!("hello world); ` into ` run_from_opt ` in [ lib/src/cli.rs] ( lib/src/ cli.rs) .
47+ ` eprintln!("hello world" ); ` into ` run_from_opt ` in [ crates/ lib/src/cli.rs] ( cli.rs ) .
5148You can run ` make ` or ` cargo build ` to build that locally. However, a key
5249next step is to get that binary into a bootc container image.
5350
54- Use e.g. ` podman build -t localhost/bootc -f hack/Containerfile . ` .
51+ Running ` just ` defaults to ` just build ` which will build a container
52+ from the current source code; the result will be named ` localhost/bootc ` .
5553
56- From there, you can create and spawn a VM from that container image
57- with your modified bootc code in exactly the same way as a systems operator
58- would test their own bootc images:
54+ ### Running an interactive shell in an environment from the container
5955
60- ```
61- $ podman-bootc run localhost/bootc
62- ```
56+ You can of course ` podman run --rm -ti localhost/bootc bash ` to get a shell,
57+ and try running ` bootc ` .
58+
59+ ### Running container-oriented integration tests
60+
61+ ` just test-container `
62+
63+ ### Running (TMT) integration tests
64+
65+ A common cycle here is you'll edit e.g. ` deploy.rs ` and want to run the
66+ tests that perform an upgrade:
67+
68+ ` just test-tmt-one test-20-local-upgrade `
6369
6470### Faster iteration cycles
6571
66- You don't need to create a whole new VM for each change, of course.
67- < https://github.com/containers/podman-bootc/pull/36 > is an outstanding
68- PR to add virtiofsd support, which would allow easily accessing the locally-built
69- binaries. Another avenue we'll likely investigate is supporting podman-bootc
70- accessing the container images which currently live in the podman-machine VM,
71- or having a local registry which frontends the built container images.
72-
73- A simple hack though (assuming your development environment is compatible
74- with the target container host) is to just run a webserver on the host, e.g.
75- ` python3 -m http.server ` or whatever, and then from the podman-bootc guest
76- run ` bootc usroverlay ` once, and
77- ` curl -L -o /usr/bin/bootc http://10.0.1.2:8080/target/release/bootc && restorecon /usr/bin/bootc ` .
72+ The test cycle currently builds a disk image and creates a new ephemeral
73+ VM for each test run.
74+
75+ You can shortcut some iteration cycles by having a more persistent
76+ environment where you run bootc.
77+
78+ #### Upgrading from the container image
79+
80+ One good approach is to create a persistent target virtual machine via e.g.
81+ ` bcvk libvirt run ` (or a cloud VM), and then after doing a ` just build ` and getting
82+ a container image, you can directly upgrade to that image.
83+
84+ For the local case, check out [ cstor-dist] ( https://github.com/cgwalters/cstor-dist ) .
85+ Another alternative is mounting via virtiofs (see e.g. [ this PR to bcvk] ( https://github.com/bootc-dev/bcvk/pull/16 ) ).
86+ If you're using libvirt, see [ this document] ( https://libvirt.org/kbase/virtiofs.html ) .
87+
88+ #### Running bootc against a live environment
89+
90+ If your development environment host is also a bootc system (e.g. a
91+ workstation or a virtual server) one way to shortcut some cycles is just
92+ to directly run the output of the built binary against your host.
93+
94+ Say for example your host is a Fedora 42 workstation (based on bootc),
95+ then you can ` cargo b --release ` directly in a Fedora 42 container
96+ or even on your host system, and then directly run e.g. ` ./target/release/bootc upgrade `
97+ etc.
98+
7899
79100### Debugging via lldb
80101
0 commit comments