@@ -34,47 +34,68 @@ accepted!
34
34
- A development environment (toolbox or a host) with a Rust and C compiler, etc.
35
35
While this isn't specific to bootc, you will find the experience of working on Rust
36
36
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 ) .
41
38
42
39
## Ensure you're familiar with a bootc system
43
40
44
41
Worth stating: before you start diving into the code you should understand using
45
42
the system as a user and how it works. See the user documentation for that.
46
43
47
- ## Creating your edit-compile-debug cycle
44
+ ## Understanding the Justfile
48
45
49
46
Edit 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 ) .
51
48
You can run ` make ` or ` cargo build ` to build that locally. However, a key
52
49
next step is to get that binary into a bootc container image.
53
50
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 ` .
55
53
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
59
55
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 `
63
69
64
70
### Faster iteration cycles
65
71
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
+
78
99
79
100
### Debugging via lldb
80
101
0 commit comments