Skip to content

Commit 566e635

Browse files
authored
Merge pull request #589 from cgwalters/doc-hacking
docs: Add HACKING.md
2 parents 6d3c89d + b867724 commit 566e635

File tree

2 files changed

+100
-4
lines changed

2 files changed

+100
-4
lines changed

HACKING.md

Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,88 @@
1+
# Hacking on bootc
2+
3+
Thanks for your interest in contributing! At the current time,
4+
bootc is implemented in Rust, and calls out to important components
5+
which are written in Go (e.g. https://github.com/containers/image)
6+
as well as C (e.g. https://github.com/ostreedev/ostree/). Depending
7+
on what area you want to work on, you'll need to be familiar with
8+
the relevant language.
9+
10+
There isn't a single approach to working on bootc; however
11+
the primary developers tend to use Linux host systems,
12+
and test in Linux VMs. One specifically recommended
13+
approach is to use [toolbox](https://github.com/containers/toolbox/)
14+
to create a containerized development environment
15+
(it's possible, though not necessary to create the toolbox
16+
dev environment using a bootc image as well).
17+
18+
At the current time most upstream developers use a Fedora derivative
19+
as a base, and the [hack/Containerfile](hack/Containerfile) defaults
20+
to Fedora. However, bootc itself is not intended to strongly tie to a particular
21+
OS or distribution, and patches to handle others are gratefully
22+
accepted!
23+
24+
## Key recommended ingredients:
25+
26+
- A development environment (toolbox or a host) with a Rust and C compiler, etc.
27+
While this isn't specific to bootc, you will find the experience of working on Rust
28+
is greatly aided with use of e.g. [rust-analyzer](https://github.com/rust-lang/rust-analyzer/).
29+
- An installation of [podman-bootc](https://github.com/containers/podman-bootc-cli)
30+
which note on Linux requires that you set up "podman machine".
31+
32+
## Ensure you're familiar with a bootc system
33+
34+
Worth stating: before you start diving into the code you should understand using
35+
the system as a user and how it works. See the user documentation for that.
36+
37+
## Creating your edit-compile-debug cycle
38+
39+
Edit the source code; a simple thing to do is add e.g.
40+
`eprintln!("hello world);` into `run_from_opt` in [lib/src/cli.rs](lib/src/cli.rs).
41+
You can run `make` or `cargo build` to build that locally. However, a key
42+
next step is to get that binary into a bootc container image.
43+
44+
Use e.g. `podman build -t localhost/bootc -f hack/Containerfile .`.
45+
46+
From there, you can create and spawn a VM from that container image
47+
with your modified bootc code in exactly the same way as a systems operator
48+
would test their own bootc images:
49+
50+
```
51+
$ podman-bootc run localhost/bootc
52+
```
53+
54+
### Faster iteration cycles
55+
56+
You don't need to create a whole new VM for each change, of course.
57+
<https://github.com/containers/podman-bootc/pull/36> is an outstanding
58+
PR to add virtiofsd support, which would allow easily accessing the locally-built
59+
binaries. Another avenue we'll likely investigate is supporting podman-bootc
60+
accessing the container images which currently live in the podman-machine VM,
61+
or having a local registry which frontends the built container images.
62+
63+
A simple hack though (assuming your development environment is compatible
64+
with the target container host) is to just run a webserver on the host, e.g.
65+
`python3 -m http.server` or whatever, and then from the podman-bootc guest
66+
run `bootc usroverlay` once, and
67+
`curl -L -o /usr/bin/bootc http://10.0.1.2:8080/target/release/bootc && restorecon /usr/bin/bootc`.
68+
69+
## Running the tests
70+
71+
First, you can run many unit tests with `cargo test`.
72+
73+
### container tests
74+
75+
There's a small set of tests which are designed to run inside a bootc container
76+
and are built into the default container image:
77+
78+
```
79+
$ podman run --rm -ti localhost/bootc bootc-integration-tests container
80+
```
81+
82+
83+
84+
85+
86+
87+
88+

README.md

Lines changed: 12 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
Transactional, in-place operating system updates using OCI/Docker container images.
44

5-
# Motivation
5+
## Motivation
66

77
The original Docker container model of using "layers" to model
88
applications has been extremely successful. This project
@@ -15,11 +15,19 @@ which is used to boot. At runtime on a target system, the base userspace is
1515
*not* itself running in a container by default. For example, assuming
1616
systemd is in use, systemd acts as pid1 as usual - there's no "outer" process.
1717

18-
# Status
18+
## Status
1919

2020
NOTE: At the current time, bootc has not reached 1.0, and it is possible
2121
that some APIs and CLIs may change.
2222

23-
# More information
23+
## Documentation
24+
25+
See the [project documentation](https://containers.github.io/bootc/); there
26+
are also operating systems and distributions using bootc; here are some examples:
27+
28+
- https://docs.fedoraproject.org/en-US/bootc/
29+
30+
## Developing bootc
31+
32+
Are you interested in working on bootc? Great! See our [HACKING.md](HACKING.md) guide.
2433

25-
See the [project documentation](https://containers.github.io/bootc/).

0 commit comments

Comments
 (0)