From 04d77b2ad57e1f261763a1d4d401bc051d0b8280 Mon Sep 17 00:00:00 2001 From: jbtrystram Date: Tue, 4 Jul 2023 15:36:02 +0200 Subject: [PATCH 01/35] cli: Add a `--check` flag for update. This simply pull the manifest of the image to see if any update and available. It could be named `--dry-run` but I wanted to be consistent with `rpm-ostree` Fixes #3 Signed-off-by: jbtrystram --- CONTRIBUTING.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..8ac8b04 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,18 @@ +# Required dependencies + +In order to build `bootc` you will need the following dependencies. + +Fedora: +``` +sudo dnf install ostree-libs ostree-devel +``` + +# Pre flight checks + +Makes sure you commented your code additions, then run +``` +cargo fmt +cargo clippy +``` +Make sure to apply any relevant suggestions. + From f97cd00a5cae0c1dcac33bc2c73f16384b334884 Mon Sep 17 00:00:00 2001 From: Micah Abbott Date: Fri, 10 Nov 2023 17:04:27 -0500 Subject: [PATCH 02/35] docs: update required dependencies In a fresh Fedora 39 container, I had to install the updated list of dependencies to successfully run: - cargo fmt - cargo clippy - cargo build --release Signed-off-by: Micah Abbott --- CONTRIBUTING.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8ac8b04..2d9bebd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,17 +2,19 @@ In order to build `bootc` you will need the following dependencies. -Fedora: -``` -sudo dnf install ostree-libs ostree-devel +Fedora: + +```bash +sudo dnf install clippy openssl-devel ostree-devel ostree-libs rustfmt ``` # Pre flight checks -Makes sure you commented your code additions, then run -``` +Make sure you commented your code additions, then run + +```bash cargo fmt cargo clippy ``` -Make sure to apply any relevant suggestions. +Make sure to apply any relevant suggestions. From 91a1cd228122a805cd2445e7d973b98ca50ce0ba Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 1 Jul 2024 18:42:32 -0400 Subject: [PATCH 03/35] Rename HACKING -> CONTRIBUTING, add info about git + PRs `CONTRIBUTING.md` is a friendlier and more common name. Explain the DCO bits in particular. Closes: https://github.com/containers/bootc/issues/574 Signed-off-by: Colin Walters --- CONTRIBUTING.md | 191 +++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 182 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2d9bebd..ceb4f7c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,20 +1,193 @@ -# Required dependencies +# Contributing to bootc -In order to build `bootc` you will need the following dependencies. +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. -Fedora: +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](https://github.com/containers/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](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! + +## Key recommended ingredients: + +- 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](https://github.com/rust-lang/rust-analyzer/). +- An installation of [podman-bootc](https://github.com/containers/podman-bootc-cli) + which note on Linux requires that you set up "podman machine". This document + assumes you have the environment variable `CONTAINER_CONNECTION` set to your + podman machine's name. + +## Ensure you're familiar with a bootc system + +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. + +## Creating your edit-compile-debug cycle + +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](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 +``` + +### Faster iteration cycles + +You don't need to create a whole new VM for each change, of course. + 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`. + +### Debugging via lldb + +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](https://libvirt.org/nss.html) +enabled. + +For some bootc install commands, it's simpler to run the lldb-server in a container, e.g. ```bash -sudo dnf install clippy openssl-devel ostree-devel ostree-libs rustfmt +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" --server +``` + +## Running the tests + +First, you can run many unit tests with `cargo test`. + +### container tests + +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 ``` -# Pre flight checks +## Submitting a patch -Make sure you commented your code additions, then run +The podman project has some [generic useful guidance](https://github.com/containers/podman/blob/main/CONTRIBUTING.md#submitting-pull-requests); +like that project, a "Developer Certificate of Origin" is required. + +### Sign your PRs + +The sign-off is a line at the end of the explanation for the patch. Your +signature certifies that you wrote the patch or otherwise have the right to pass +it on as an open-source patch. The rules are simple: if you can certify +the below (from [developercertificate.org](https://developercertificate.org/)): + +``` +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +660 York Street, Suite 102, +San Francisco, CA 94110 USA + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. +``` + +Then you just add a line to every git commit message: + + Signed-off-by: Joe Smith + +Use your real name (sorry, no pseudonyms or anonymous contributions.) + +If you set your `user.name` and `user.email` git configs, you can sign your +commit automatically with `git commit -s`. + +### Git commit style + +Please look at `git log` and match the commit log style, which is very +similar to the +[Linux kernel](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git). + +You may use `Signed-off-by`, but we're not requiring it. + +**General Commit Message Guidelines**: + +1. Title + - Specify the context or category of the changes e.g. `lib` for library changes, `docs` for document changes, `bin/` for command changes, etc. + - Begin the title with the first letter of the first word capitalized. + - Aim for less than 50 characters, otherwise 72 characters max. + - Do not end the title with a period. + - Use an [imperative tone](https://en.wikipedia.org/wiki/Imperative_mood). +2. Body + - Separate the body with a blank line after the title. + - Begin a paragraph with the first letter of the first word capitalized. + - Each paragraph should be formatted within 72 characters. + - Content should be about what was changed and why this change was made. + - If your commit fixes an issue, the commit message should end with `Closes: #`. + +Commit Message example: ```bash -cargo fmt -cargo clippy +: Less than 50 characters for subject title + +A paragraph of the body should be within 72 characters. + +This paragraph is also less than 72 characters. ``` -Make sure to apply any relevant suggestions. +For more information see [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) From 2f64f3a5c1838e6e3837042571d393b1d85bdf90 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 15 Jul 2024 17:44:59 -0400 Subject: [PATCH 04/35] build-sys: Add `make validate-rust` The `make validate-rust` reproduces locally the same checks we run in CI as gating by default; hook it up to the existing `make validate`. Signed-off-by: Colin Walters --- CONTRIBUTING.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ceb4f7c..c398531 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -85,6 +85,11 @@ For some bootc install commands, it's simpler to run the lldb-server in a contai 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" --server ``` +## Code linting + +The `make validate` target runs checks locally that we gate on +in CI, currently around `cargo fmt` and `cargo clippy`. + ## Running the tests First, you can run many unit tests with `cargo test`. From 66f1332cecf48c8ab8eea1d4f2e9630a240e406a Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Fri, 18 Oct 2024 09:29:43 -0400 Subject: [PATCH 05/35] CONTRIBUTING: Recommend filing an issue before big PRs Signed-off-by: Colin Walters --- CONTRIBUTING.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c398531..1c3da2d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -7,6 +7,14 @@ 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. +## Note: Before writing a big patch + +If you plan to contribute a large change, please get in touch *before* +submitting a pull request by e.g. filing an issue describing your proposed +change. This will help ensure alignment. + +## Development environment + 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 From 269813e03229482d02bdcedbcab3c0fd2e084f18 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 22 Oct 2024 15:05:38 -0400 Subject: [PATCH 06/35] Add MAINTAINERS.md and ADOPTERS.md These files help clarify/formalize some information. In particular I'd like to look at tools that auto-sync from MAINTAINERS to the github permissions so that we can maintain that in a git-ops fashion. Signed-off-by: Colin Walters --- ADOPTERS.md | 37 +++++++++++++++++++++++++++++++++++++ MAINTAINERS.md | 9 +++++++++ 2 files changed, 46 insertions(+) create mode 100644 ADOPTERS.md create mode 100644 MAINTAINERS.md diff --git a/ADOPTERS.md b/ADOPTERS.md new file mode 100644 index 0000000..822595a --- /dev/null +++ b/ADOPTERS.md @@ -0,0 +1,37 @@ + +> **Note** +> Do you want to add yourself to this list? Simply fork the repository and open a PR with the required change. +> We have a short description of the adopter types at the bottom of this page. Each type is in alphabetical order. + +# bootc Adopters (direct) + +| Type | Name | Since | Website | Use-Case | +|:-|:-|:-|:-|:-| +Vendor | Red Hat | 2024 | https://redhat.com | Image Based Linux +End-User | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operating system for your devices + +# bootc Adopters (indirect, via ostree) + +Bootc is a relatively new project, but much of the underlying technology and goals is *not* new. +The underlying ostree project is over 13 years old (as of 2024). This project also relates +to [rpm-ostree](https://github.com/coreos/rpm-ostree/) which has existed a really long time. + +Not every one of these projects uses bootc directly today, but a toplevel goal of bootc +is to be the successor to ostree, and it is our aim to seamlessly carry forward these users. + +| Type | Name | Since | Website | Use-Case | +|:-|:-|:-|:-|:-| +| Vendor | Endless | 2014 | [link](https://www.endlessos.org/os) | A Completely Free, User-Friendly Operating System Packed with Educational Tools, Games, and More +| Vendor | Red Hat | 2015 | [link](https://redhat.com) | Image Based Linux +| Vendor | Apertis | 2020 | [link](https://apertis.org) | Collaborative OS platform for products +| Vendor | Fedora Project | 2021 | [link](https://fedoraproject.org/atomic-desktops/) | An atomic desktop operating system aimed at good support for container-focused workflows +| Vendor | UBlue | 2023 | [link](https://universal-blue.org/) | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop + +### Adopter Types + +**End-user**: The organization runs bootc in production in some way. + +**Integration**: The organization has a product that integrates with bootc, but does not contain bootc. + +**Vendor**: The organization packages bootc in their product and sells it as part of their product. + diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 0000000..9b602b2 --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,9 @@ +# Maintainers + +The current Maintainers Group for the bootc Project consists of: + +| Name | GitHub ID | Employer | Responsibilities | +| ---- | ---- | ---- | ---- | +| Chris Kyrouac | [ckyrouac](https://github.com/orgs/containers/people/ckyrouac) | Red Hat | Approver | +| Colin Walters | [cgwalters](https://github.com/orgs/containers/people/cgwalters) | Red Hat | Approver | +| John Eckersberg | [jeckersb](https://github.com/orgs/containers/people/jeckersb) | Red Hat | Approver | From 7f13a3458aaaaa77e44ea3ef4ce032ea5bdd6bbc Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Thu, 31 Oct 2024 23:35:24 -0400 Subject: [PATCH 07/35] docs: Update ADOPTERS.md Copyedit the universal blue entry. Signed-off-by: Jorge O. Castro --- ADOPTERS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ADOPTERS.md b/ADOPTERS.md index 822595a..f914d05 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -25,7 +25,7 @@ is to be the successor to ostree, and it is our aim to seamlessly carry forward | Vendor | Red Hat | 2015 | [link](https://redhat.com) | Image Based Linux | Vendor | Apertis | 2020 | [link](https://apertis.org) | Collaborative OS platform for products | Vendor | Fedora Project | 2021 | [link](https://fedoraproject.org/atomic-desktops/) | An atomic desktop operating system aimed at good support for container-focused workflows -| Vendor | UBlue | 2023 | [link](https://universal-blue.org/) | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop +| Vendor | Universal Blue | 2022 | [link](https://universal-blue.org/) | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop ### Adopter Types From d18aeb6cc99d0c8793decae6a973d135a7582fa3 Mon Sep 17 00:00:00 2001 From: Jaiden Riordan Date: Sun, 29 Dec 2024 18:13:01 -0600 Subject: [PATCH 08/35] ADOPTERS: Add fyra/ultramarine Signed-off-by: Colin Walters Signed-off-by: Laura Santamaria --- ADOPTERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADOPTERS.md b/ADOPTERS.md index f914d05..eec948f 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -26,6 +26,7 @@ is to be the successor to ostree, and it is our aim to seamlessly carry forward | Vendor | Apertis | 2020 | [link](https://apertis.org) | Collaborative OS platform for products | Vendor | Fedora Project | 2021 | [link](https://fedoraproject.org/atomic-desktops/) | An atomic desktop operating system aimed at good support for container-focused workflows | Vendor | Universal Blue | 2022 | [link](https://universal-blue.org/) | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop +| Vendor | Fyra Labs | 2024 | [link](https://fyralabs.com) | Bootc powers an experimental variant of Ultramarine Linux ### Adopter Types From 37cc452a723ddeb2fe19cc33bf7d9b3abe923dee Mon Sep 17 00:00:00 2001 From: gursewak1997 Date: Mon, 10 Mar 2025 21:44:22 -0700 Subject: [PATCH 09/35] Maintainers.md: Update and add users Signed-off-by: Laura Santamaria --- MAINTAINERS.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 9b602b2..f9d4eac 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -4,6 +4,8 @@ The current Maintainers Group for the bootc Project consists of: | Name | GitHub ID | Employer | Responsibilities | | ---- | ---- | ---- | ---- | -| Chris Kyrouac | [ckyrouac](https://github.com/orgs/containers/people/ckyrouac) | Red Hat | Approver | -| Colin Walters | [cgwalters](https://github.com/orgs/containers/people/cgwalters) | Red Hat | Approver | -| John Eckersberg | [jeckersb](https://github.com/orgs/containers/people/jeckersb) | Red Hat | Approver | +| Chris Kyrouac | [ckyrouac](https://github.com/orgs/bootc-dev/people/ckyrouac) | Red Hat | Approver | +| Colin Walters | [cgwalters](https://github.com/orgs/bootc-dev/people/cgwalters) | Red Hat | Approver | +| John Eckersberg | [jeckersb](https://github.com/orgs/bootc-dev/people/jeckersb) | Red Hat | Approver | +| Gursewak Mangat | [gurusewak](https://github.com/orgs/bootc-dev/people/gursewak1997) | Red Hat | Approver | +| Joseph Corchado | [jeckersb](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver | From ab5cfb9c31aa77e64ab28dd2bae776687af4ca72 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Thu, 13 Mar 2025 08:14:18 -0400 Subject: [PATCH 10/35] MAINTAINERS.md: Add henrywang He'll be at least helping maintain CI and approving issues related to that. Signed-off-by: Laura Santamaria --- MAINTAINERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index f9d4eac..4f3e24a 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -7,5 +7,6 @@ The current Maintainers Group for the bootc Project consists of: | Chris Kyrouac | [ckyrouac](https://github.com/orgs/bootc-dev/people/ckyrouac) | Red Hat | Approver | | Colin Walters | [cgwalters](https://github.com/orgs/bootc-dev/people/cgwalters) | Red Hat | Approver | | John Eckersberg | [jeckersb](https://github.com/orgs/bootc-dev/people/jeckersb) | Red Hat | Approver | +| Xiaofeng Wang | [henrywang](https://github.com/orgs/bootc-dev/people/henrywang) | Red Hat | Approver | | Gursewak Mangat | [gurusewak](https://github.com/orgs/bootc-dev/people/gursewak1997) | Red Hat | Approver | | Joseph Corchado | [jeckersb](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver | From 215c41864e032c3020ae09c4a51057108452b395 Mon Sep 17 00:00:00 2001 From: Joseph Marrero Corchado Date: Mon, 17 Mar 2025 14:08:34 -0400 Subject: [PATCH 11/35] MAINTAINERS: fix jmarrero username and last name Signed-off-by: Laura Santamaria --- MAINTAINERS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 4f3e24a..453fe61 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -9,4 +9,4 @@ The current Maintainers Group for the bootc Project consists of: | John Eckersberg | [jeckersb](https://github.com/orgs/bootc-dev/people/jeckersb) | Red Hat | Approver | | Xiaofeng Wang | [henrywang](https://github.com/orgs/bootc-dev/people/henrywang) | Red Hat | Approver | | Gursewak Mangat | [gurusewak](https://github.com/orgs/bootc-dev/people/gursewak1997) | Red Hat | Approver | -| Joseph Corchado | [jeckersb](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver | +| Joseph Marrero | [jmarrero](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver | From 07a27f889a075b451acdf4991d60e0930ef0cbaf Mon Sep 17 00:00:00 2001 From: Joseph Marrero Corchado Date: Mon, 10 Mar 2025 21:09:57 -0400 Subject: [PATCH 12/35] GOVERNANCE: Add Governance doc for CNCF onboarding This is implementing https://github.com/cncf/project-template/blob/main/GOVERNANCE-maintainer.md Co-authored-by: Colin Walters Signed-off-by: Joseph Marrero Corchado Signed-off-by: Colin Walters --- GOVERNANCE.md | 152 ++++++++++++++++++++++++++++++++++++++++++++++++++ SECURITY.md | 19 +++++++ 2 files changed, 171 insertions(+) create mode 100644 GOVERNANCE.md create mode 100644 SECURITY.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 0000000..01c5d04 --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,152 @@ +# Bootc Project Governance + +The Bootc project is dedicated to providing transactional, in-place operating system updates using OCI/Docker container images. +This governance explains how the project is run. + +- [Values](#values) +- [Maintainers](#maintainers) +- [Becoming a Maintainer](#becoming-a-maintainer) +- [Meetings](#meetings) +- [CNCF Resources](#cncf-resources) +- [Code of Conduct Enforcement](#code-of-conduct) +- [Security Response Team](#security-response-team) +- [Voting](#voting) +- [Modifications](#modifying-this-charter) + +## Values + +The Bootc and its leadership embrace the following values: + +* Openness: Communication and decision-making happens in the open and is discoverable for future + reference. As much as possible, all discussions and work take place in public + forums and open repositories. + +* Fairness: All stakeholders have the opportunity to provide feedback and submit + contributions, which will be considered on their merits. + +* Community over Product or Company: Sustaining and growing our community takes + priority over shipping code or sponsors' organizational goals. Each + contributor participates in the project as an individual. + +* Inclusivity: We innovate through different perspectives and skill sets, which + can only be accomplished in a welcoming and respectful environment. + +* Participation: Responsibilities within the project are earned through + participation, and there is a clear path up the contributor ladder into leadership + positions. + +## Maintainers + +Bootc Maintainers have "gated" write acess to the [project GitHub repository](https://github.com/bootc-dev/bootc). +The current maintainers can be found in [MAINTAINERS.md](./MAINTAINERS.md). + +Direct pushes to the code is never allowed. All pull requests require review by a maintainer +*other* than the one submitting it. "Large" changes are encouraged to have a tracking +issue filed beforehand and gather consensus from multiple maintainers and interested community. + +Maintainers collectively manage the project's resources and contributors. + +This privilege is granted with some expectation of responsibility: maintainers +are people who care about the Bootc project and want to help it grow and +improve. A maintainer is not just someone who can make changes, but someone who +has demonstrated their ability to collaborate with the team, get the most +knowledgeable people to review code and docs, contribute high-quality code, and +follow through to fix issues (in code or tests). + +A maintainer is a contributor to the project's success and a citizen helping +the project succeed. + +The collective team of all Maintainers is known as the Maintainer Council, which +is the governing body for the project. + +### Becoming a Maintainer + +To become a Maintainer you need to demonstrate the following: + + * commitment to the project: + * participate in discussions, contributions, code and documentation reviews for 6 months or more, + * perform reviews for 20 non-trivial pull requests, + * contribute 10 non-trivial pull requests and have them merged, + * ability to write quality code and/or documentation, + * ability to collaborate with the team, + * understanding of how the team works (policies, processes for testing and code review, etc), + * understanding of the project's code base and coding and documentation style. + +A new Maintainer must be proposed by an existing maintainer by opening a PR against the [MAINTAINERS.md](./MAINTAINERS.md), which will prompt a [gitvote](https://github.com/cncf/gitvote). A simple majority vote of existing Maintainers +approves the application. Maintainers nominations will be evaluated without prejudice +to employer or demographics. + +Maintainers who are selected will be granted the necessary GitHub rights. + +### Removing a Maintainer + +Maintainers may resign at any time if they feel that they will not be able to +continue fulfilling their project duties. + +Maintainers may also be removed after being inactive, failure to fulfill their +Maintainer responsibilities, violating the Code of Conduct, or other reasons. +Inactivity is defined as a period of very low or no activity in the project +for a year or more, with no definite schedule to return to full Maintainer +activity. + +A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers. + +Depending on the reason for removal, a Maintainer may be converted to Emeritus +status. Emeritus Maintainers will still be consulted on some project matters, +and can be rapidly returned to Maintainer status if their availability changes. +This requires two votes from active maintainers. + +## Meetings + +Time zones permitting, Maintainers are expected to participate in the public +developer meeting, which occurs at 3:30 PM ET on Thursdays via [Zoom](TODO). + +Maintainers will also have closed meetings in order to discuss security reports +or Code of Conduct violations. Such meetings should be scheduled by any +Maintainer on receipt of a security issue or CoC report. All current Maintainers +must be invited to such closed meetings, except for any Maintainer who is +accused of a CoC violation. + +## CNCF Resources + +Any Maintainer may suggest a request for CNCF resources, either in the +[bootc discussions](https://github.com/bootc-dev/bootc/discussions), or during a +meeting. A simple majority of Maintainers approves the request. The Maintainers +may also choose to delegate working with the CNCF to non-Maintainer community +members, who will then be added to the [CNCF's Maintainer List](https://github.com/cncf/foundation/blob/main/project-maintainers.csv) +for that purpose. + +## Code of Conduct + +[Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) +violations by community members will be discussed and resolved +by the maintainers privately. If a Maintainer is directly involved +in the report, the Maintainers will instead designate two Maintainers to work +with the CNCF Code of Conduct Committee in resolving it. + +## Security Response Team + +The Maintainers will appoint a Security Response Team to handle security reports. +This committee may simply consist of the Maintainer Council themselves. If this +responsibility is delegated, the Maintainers will appoint a team of at least two +contributors to handle it. The Maintainers will review who is assigned to this +at least once a year. + +The Security Response Team is responsible for handling all reports of security +holes and breaches according to the [security policy](./SECURITY.md). + +## Voting + +While most business in Bootc is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)", +periodically the Maintainers may need to vote on specific actions or changes. +A vote can be taken using [gitvote](https://github.com/cncf/gitvote) or +privately for security or conduct matters. Any Maintainer may demand a vote be taken. + +Most votes require a simple majority of all Maintainers to succeed, except where +otherwise noted. Two-thirds majority votes mean at least two-thirds of all +existing maintainers. + +## Modifying this Charter + +Changes to this Governance and its supporting documents may be approved by +a 2/3 vote of the Maintainers. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..63d3e04 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,19 @@ +# Security Policy + +## Reporting a Vulnerability + +If you find a potential security vulnerability in bootc, please report it by following these steps: + +### 1. **Use the GitHub Security Tab** +This repository is set up to allow vulnerability reports through GitHub's Security Advisories feature. To report a vulnerability: + +1. Navigate to the repository's main page. +2. Select the [**Security**](https://github.com/bootc-dev/bootc/security) tab. +3. Select **Advisories** from the left-hand sidebar. +4. Click on **Report a vulnerability**. +5. Fill in the required details and submit the report. + +Following this process will create a private advisory for our maintainers to review. + +### 2. **Do Not Open Public Pull Requests, Issues, or Discussions** +Please **do not** discuss the issue, create PRs, or start discussions about the vulnerability. This ensures the vulnerability is not widely exploited before a fix is provided. From b06cd84b545b66bf6678d5eb65f5b8e7c714dffd Mon Sep 17 00:00:00 2001 From: gursewak1997 Date: Mon, 31 Mar 2025 12:49:13 -0700 Subject: [PATCH 13/35] Fix name typo in Maintainers list Signed-off-by: Laura Santamaria --- MAINTAINERS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 453fe61..1dd7bc9 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -8,5 +8,5 @@ The current Maintainers Group for the bootc Project consists of: | Colin Walters | [cgwalters](https://github.com/orgs/bootc-dev/people/cgwalters) | Red Hat | Approver | | John Eckersberg | [jeckersb](https://github.com/orgs/bootc-dev/people/jeckersb) | Red Hat | Approver | | Xiaofeng Wang | [henrywang](https://github.com/orgs/bootc-dev/people/henrywang) | Red Hat | Approver | -| Gursewak Mangat | [gurusewak](https://github.com/orgs/bootc-dev/people/gursewak1997) | Red Hat | Approver | +| Gursewak Mangat | [gursewak1997](https://github.com/orgs/bootc-dev/people/gursewak1997)| Red Hat | Approver | | Joseph Marrero | [jmarrero](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver | From adf94fbf25b0e257d3f53f2c79f855dffe16e79a Mon Sep 17 00:00:00 2001 From: John Eckersberg Date: Fri, 13 Jun 2025 11:50:55 -0400 Subject: [PATCH 14/35] README.md: Add details for Friday Zoom meeting Signed-off-by: John Eckersberg --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 01c5d04..c3276f5 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -99,7 +99,7 @@ This requires two votes from active maintainers. ## Meetings Time zones permitting, Maintainers are expected to participate in the public -developer meeting, which occurs at 3:30 PM ET on Thursdays via [Zoom](TODO). +developer meeting, which occurs at 15:30 UTC on Fridays via [Zoom](https://zoom-lfx.platform.linuxfoundation.org/meeting/96540875093?password=7889708d-c520-4565-90d3-ce9e253a1f65). Maintainers will also have closed meetings in order to discuss security reports or Code of Conduct violations. Such meetings should be scheduled by any From 947ca114d4250b7e3cd4f4ea3ff884eabcf36ead Mon Sep 17 00:00:00 2001 From: imbev Date: Tue, 29 Jul 2025 07:55:02 -0500 Subject: [PATCH 15/35] Update ADOPTERS.md: Label HeliumOS as vendor, not end-user Signed-off-by: Laura Santamaria --- ADOPTERS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ADOPTERS.md b/ADOPTERS.md index eec948f..f60136d 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -8,7 +8,7 @@ | Type | Name | Since | Website | Use-Case | |:-|:-|:-|:-|:-| Vendor | Red Hat | 2024 | https://redhat.com | Image Based Linux -End-User | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operating system for your devices +Vendor | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operating system for your devices # bootc Adopters (indirect, via ostree) From 6a8dad0230e7daad4d33fd64df354e7683fb021a Mon Sep 17 00:00:00 2001 From: Luke Short Date: Wed, 30 Jul 2025 16:26:48 -0600 Subject: [PATCH 16/35] docs: add Playtron GameOS to the ADOPTERS.md. We have builds dating all the way back to 2022. Signed-off-by: Luke Short --- ADOPTERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADOPTERS.md b/ADOPTERS.md index f60136d..1a5b28b 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -25,6 +25,7 @@ is to be the successor to ostree, and it is our aim to seamlessly carry forward | Vendor | Red Hat | 2015 | [link](https://redhat.com) | Image Based Linux | Vendor | Apertis | 2020 | [link](https://apertis.org) | Collaborative OS platform for products | Vendor | Fedora Project | 2021 | [link](https://fedoraproject.org/atomic-desktops/) | An atomic desktop operating system aimed at good support for container-focused workflows +| Vendor | Playtron GameOS | 2022 | [link](https://www.playtron.one/) | A video game console OS that has integration with the top PC game stores | | Vendor | Universal Blue | 2022 | [link](https://universal-blue.org/) | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop | Vendor | Fyra Labs | 2024 | [link](https://fyralabs.com) | Bootc powers an experimental variant of Ultramarine Linux From 343a1d1406e982b81f1f3d631b4912db555fd197 Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Thu, 21 Aug 2025 10:16:45 -0400 Subject: [PATCH 17/35] governance: add community manager role Feel free to adjust wording as needed, this is just an example. This is a good way to empower PMs other folks to be able to help out with meta things around the project. We explicitly list the the role in governance so that the people listed here end up in the main cncf maintainers.csv. Being in the csv file is important because it is a check the CNCF uses to ensure maintainers are requesting the resources. And for CFP submissions, "did one of the maintainers submit this talk or was it someone else?", etc. Signed-off-by: Laura Santamaria --- MAINTAINERS.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 1dd7bc9..12ee6e7 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -10,3 +10,11 @@ The current Maintainers Group for the bootc Project consists of: | Xiaofeng Wang | [henrywang](https://github.com/orgs/bootc-dev/people/henrywang) | Red Hat | Approver | | Gursewak Mangat | [gursewak1997](https://github.com/orgs/bootc-dev/people/gursewak1997)| Red Hat | Approver | | Joseph Marrero | [jmarrero](https://github.com/orgs/bootc-dev/people/jmarrero) | Red Hat | Approver | + +# Community Managers + +This group can represent the project for administrative and program manager duties. Examples: CNCF Service Desk tickets, coordinating with CNCF Project and Events teams, and LFX Administration. No code or code review rights. + +| Name | GitHub ID | Employer | Responsibilities | +| ---- | ---- | ---- | ---- | +| Laura Santamaria | [nimbinatus](https://github.com/nimbinatus) | Red Hat | Representative | From 2530ff759a6889f0dff7211901e101745bb6afb4 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 22 Sep 2025 14:48:13 -0400 Subject: [PATCH 18/35] Updates to build sys and CONTRIBUTING.md The emphasis here is on trying to have the `Justfile` be the default entrypoint, wrapping other tools. - Replace mentions of podman-bootc with bcvk since I hope the latter supercedes the former - Unify the unit test entrypoint - Set up /var/tmp as a tmpdir to fix the etc merge test (otherwise, selinux failures w/tmp) - Run the unit+container tests in integration.yml - Have `just validate` run in a container Signed-off-by: Colin Walters --- CONTRIBUTING.md | 71 ++++++++++++++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 25 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1c3da2d..151cd0e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -34,47 +34,68 @@ 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](https://github.com/rust-lang/rust-analyzer/). -- An installation of [podman-bootc](https://github.com/containers/podman-bootc-cli) - which note on Linux requires that you set up "podman machine". This document - assumes you have the environment variable `CONTAINER_CONNECTION` set to your - podman machine's name. +- Install [bcvk](https://github.com/bootc-dev/bcvk). ## Ensure you're familiar with a bootc system 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. -## Creating your edit-compile-debug cycle +## Understanding the Justfile 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](lib/src/cli.rs). +`eprintln!("hello world");` into `run_from_opt` in [crates/lib/src/cli.rs](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 .`. +Running `just` defaults to `just build` which will build a container +from the current source code; the result will be named `localhost/bootc`. -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: +### Running an interactive shell in an environment from the container -``` -$ podman-bootc run localhost/bootc -``` +You can of course `podman run --rm -ti localhost/bootc bash` to get a shell, +and try running `bootc`. + +### Running container-oriented integration tests + +`just test-container` + +### Running (TMT) integration tests + +A common cycle here is you'll edit e.g. `deploy.rs` and want to run the +tests that perform an upgrade: + +`just test-tmt-one test-20-local-upgrade` ### Faster iteration cycles -You don't need to create a whole new VM for each change, of course. - 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 test cycle currently builds a disk image and creates a new ephemeral +VM for each test run. + +You can shortcut some iteration cycles by having a more persistent +environment where you run bootc. + +#### Upgrading from the container image + +One good approach is to create a persistent target virtual machine via e.g. +`bcvk libvirt run` (or a cloud VM), and then after doing a `just build` and getting +a container image, you can directly upgrade to that image. + +For the local case, check out [cstor-dist](https://github.com/cgwalters/cstor-dist). +Another alternative is mounting via virtiofs (see e.g. [this PR to bcvk](https://github.com/bootc-dev/bcvk/pull/16)). +If you're using libvirt, see [this document](https://libvirt.org/kbase/virtiofs.html). + +#### Running bootc against a live environment + +If your development environment host is also a bootc system (e.g. a +workstation or a virtual server) one way to shortcut some cycles is just +to directly run the output of the built binary against your host. + +Say for example your host is a Fedora 42 workstation (based on bootc), +then you can `cargo b --release` directly in a Fedora 42 container +or even on your host system, and then directly run e.g. `./target/release/bootc upgrade` +etc. + ### Debugging via lldb From 593f377efeb6742e97e35f14c4d54f1551d0949f Mon Sep 17 00:00:00 2001 From: mohan-shash <162627980+mohan-shash@users.noreply.github.com> Date: Fri, 3 Oct 2025 11:38:41 -0400 Subject: [PATCH 19/35] Update MAINTAINERS.md Added myself as the maintainer, needed for contributing videos to CNCF channel. Signed-off-by: mohan-shash <162627980+mohan-shash@users.noreply.github.com> --- MAINTAINERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 12ee6e7..0488a13 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -18,3 +18,4 @@ This group can represent the project for administrative and program manager duti | Name | GitHub ID | Employer | Responsibilities | | ---- | ---- | ---- | ---- | | Laura Santamaria | [nimbinatus](https://github.com/nimbinatus) | Red Hat | Representative | +| Mohan Shash | [mohan-shash](https://github.com/mohan-shash) | Red Hat | Representative | From 49dd807355769fe3a1dd5560e398125ea5c9583d Mon Sep 17 00:00:00 2001 From: Pragyan Poudyal Date: Wed, 26 Nov 2025 15:32:27 +0530 Subject: [PATCH 20/35] project: Fix typos Fix a few typos across the project. Also update some comments/error messages Signed-off-by: Pragyan Poudyal --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index c3276f5..13e8ab0 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -37,7 +37,7 @@ The Bootc and its leadership embrace the following values: ## Maintainers -Bootc Maintainers have "gated" write acess to the [project GitHub repository](https://github.com/bootc-dev/bootc). +Bootc Maintainers have "gated" write access to the [project GitHub repository](https://github.com/bootc-dev/bootc). The current maintainers can be found in [MAINTAINERS.md](./MAINTAINERS.md). Direct pushes to the code is never allowed. All pull requests require review by a maintainer From 2dce9122a68e08aca3001fdfd06a48f40abe1917 Mon Sep 17 00:00:00 2001 From: "bootc-bot[bot]" <225049296+bootc-bot[bot]@users.noreply.github.com> Date: Mon, 29 Dec 2025 13:31:32 +0000 Subject: [PATCH 21/35] Sync common files from infra repository (#1875) Synchronized from bootc-dev/infra@d5a5a62c9810a416e4cc98f377c05343393f7c14. Signed-off-by: bootc-dev Bot Co-authored-by: bootc-dev Bot --- REVIEW.md | 173 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 REVIEW.md diff --git a/REVIEW.md b/REVIEW.md new file mode 100644 index 0000000..80e6f4d --- /dev/null +++ b/REVIEW.md @@ -0,0 +1,173 @@ +# Code Review Guidelines + +These guidelines are derived from analysis of code reviews across the bootc-dev +organization (October–December 2024). They represent the collective expectations +and standards that have emerged from real review feedback. + +## Testing + +Tests are expected for all non-trivial changes - unit and integration by default. + +If there's something that's difficult to write a test for at the current time, +please do at least state if it was tested manually. + +### Choosing the Right Test Type + +Unit tests are appropriate for parsing logic, data transformations, and +self-contained functions. Use integration tests for anything that involves +running containers or VMs. + +Default to table-driven tests instead of having a separate unit test per +case. Especially LLMs like to generate the latter, but it can become +too verbose. Context windows matter to both humans and LLMs reading the +code later (this applies outside of unit tests too of course, but it's +easy to generate a *lot* of code for unit tests unnecessarily). + +### Separating Parsing from I/O + +A recurring theme is structuring code for testability. Split parsers from data +reading: have the parser accept a `&str`, then have a separate function that +reads from disk and calls the parser. This makes unit testing straightforward +without filesystem dependencies. + +### Test Assertions + +Make assertions strict and specific. Don't just verify that code "didn't crash"— +check that outputs match expected values. When adding new commands or output +formats, tests should verify the actual content, not just that something was +produced. + +## Code Quality + +### Parsing Structured Data + +Never parse structured data formats (JSON, YAML, XML) with text tools like `grep` +or `sed`. + +### Shell Scripts + +Try to avoid having shell script longer than 50 lines. This commonly occurs +in build system and tests. For the build system, usually there's higher +level ways to structure things (Justfile e.g.) and several of our projects +use the `cargo xtask` pattern to put arbitrary "glue" code in Rust using +the `xshell` crate to keep it easy to run external commands. + +### Constants and Magic Values + +Extract magic numbers into named constants. Any literal number that isn't +immediately obvious—buffer sizes, queue lengths, retry counts, timeouts—should +be a constant with a descriptive name. The same applies to magic strings: +deduplicate repeated paths, configuration keys, and other string literals. + +When values aren't self-explanatory, add a comment explaining why that specific +value was chosen. + +### Don't ignore (swallow) errors + +Avoid the `if let Ok(v) = ... { }` in Rust, or `foo 2>/dev/null || true` +pattern in shell script by default. Most errors should be propagated by +default. If not, it's usually appropriate to at least log error messages +at a `tracing::debug!` or equivalent level. + +Handle edge cases explicitly: missing data, malformed input, offline systems. +Error messages should provide clear context for diagnosis. + +### Code Organization + +Separate concerns: I/O operations, parsing logic, and business logic belong in +different functions. Structure code so core logic can be unit tested without +external dependencies. + +It can be OK to duplicate a bit of code in a slightly different form twice, +but having it happen in 3 places asks for deduplication. + +## Commits and Pull Requests + +### Commit Organization + +Break changes into logical, atomic commits. Reviewers appreciate being able to +follow your reasoning: "Especially grateful for breaking it up into individual +commits so I can more easily follow your train of thought." + +Preparatory refactoring should be separate from behavioral changes. Each commit +should tell a clear story and be reviewable independently. Commit messages should +explain the "why" not just the "what," and use imperative mood ("Add feature" +not "Added feature"). + +### PR Descriptions + +PRs should link to the issues they address using `Closes:` or `Fixes:` with +full URLs. One reviewer noted: "I edited this issue just now to have +`Closes: ` but let's try to be sure we're doing that kind of thing in +general in the future." + +Document known limitations and caveats explicitly. When approaches have tradeoffs +or don't fully solve a problem, say so. For complex investigations, use collapsible +`
` sections to include debugging notes without cluttering the main +description. + +Think about broader implications: "But we'll have this problem across all repos +right?" Consider how your change affects the wider ecosystem. + +### Keeping PRs Current + +Keep PRs rebased on main. When CI failures are fixed in other PRs, rebase to +pick up the fixes. Reference the fixing PR when noting that a rebase is needed. + +### Before Merge + +Self-review your diff before requesting review. Catch obvious issues yourself +rather than burning reviewer cycles. + +Do not add `Signed-off-by` lines automatically—these require explicit human +action after review. If code was AI-assisted, include an `Assisted-by:` trailer +indicating the tool and model used. + + +## Architecture and Design + +### Workarounds vs Proper Fixes + +When implementing a workaround, document where the proper fix belongs and link +to relevant upstream issues. Invest time investigating proper fixes before +settling on workarounds. + +### Cross-Project Considerations + +Prefer pushing fixes upstream when the root cause is in a dependency. Reduce +scope where possible; don't reimplement functionality that belongs elsewhere. + +When multiple systems interact (like Renovate and custom sync tooling), be +explicit about which system owns what and how they coordinate. + +### Avoiding Regressions + +Verify that new code paths handle all cases the old code handled. When rewriting +functionality, ensure equivalent coverage exists. + +### Review Requirements + +When multiple contributors co-author a PR, bring in an independent reviewer. + +## Rust-Specific Guidance + +Prefer rustix over `libc`. All `unsafe` code must be very carefully +justified. + +### Dependencies + +New dependencies should be justified. Glance at existing reverse dependencies +on crates.io to see if a crate is widely used. Consider alternatives: "I'm +curious if you did any comparative analysis at all with alternatives?" + +Prefer well-maintained crates with active communities. Consider `cargo deny` +policies when adding dependencies. + +### API Design + +When adding new commands or options, think about machine-readable output early. +JSON is generally preferred for that. + +Keep helper functions in appropriate modules. Move command output formatting +close to the CLI layer, keeping core logic functions focused on their primary +purpose. From d70a1d17e8bbb7c87e76914ac186267dc22bad3c Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 6 Jan 2026 14:56:15 -0500 Subject: [PATCH 22/35] build-sys: Remove separate integration test image The previous commit consolidated test content (nushell, cloud-init, etc.) into the base image. This completes that work by removing the separate `build-integration-test-image` target and updating all references. Now `just build` produces the complete test-ready image directly, simplifying the build pipeline and eliminating the intermediate `localhost/bootc-integration` image. Also adds SKIP_CONFIGS support for the coreos testing workflow, which skips LBIs, test kargs, and install configs that would conflict with FCOS. Signed-off-by: Colin Walters --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 151cd0e..b395bd5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -129,7 +129,7 @@ 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 +$ just test-container ``` ## Submitting a patch From 29a74869ad1d1d6a58c86a5d59659640a911e4b7 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Fri, 16 Jan 2026 08:57:17 -0500 Subject: [PATCH 23/35] docs: Improve Justfile with groups and self-documenting targets Justfile changes: - Organize targets into groups (core, testing, docs, debugging, maintenance) - Add `list-variants` target to show available build variants - Simplify comments to be concise single-line descriptions - Move composefs targets (build-sealed, test-composefs) into core group CONTRIBUTING.md changes: - Reference `just --list` and `just list-variants` instead of duplicating - Remove tables that duplicate Justfile information - Fix broken link to cli.rs The Justfile is now self-documenting via `just --list` (grouped targets) and `just list-variants` (build configuration options). Assisted-by: OpenCode (Claude Sonnet 4) Signed-off-by: Colin Walters --- CONTRIBUTING.md | 49 ++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 44 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b395bd5..31d217f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -41,11 +41,20 @@ accepted! 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. -## Understanding the Justfile +## The Justfile + +The [Justfile](Justfile) is the primary interface for building and testing bootc. + +```bash +just --list # Show all targets organized by group +just list-variants # Show available build variants and current config +``` + +### Building from source Edit the source code; a simple thing to do is add e.g. -`eprintln!("hello world");` into `run_from_opt` in [crates/lib/src/cli.rs](cli.rs). -You can run `make` or `cargo build` to build that locally. However, a key +`eprintln!("hello world");` into `run_from_opt` in [crates/lib/src/cli.rs](crates/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. Running `just` defaults to `just build` which will build a container @@ -58,14 +67,24 @@ and try running `bootc`. ### Running container-oriented integration tests -`just test-container` +```bash +just test-container +``` ### Running (TMT) integration tests A common cycle here is you'll edit e.g. `deploy.rs` and want to run the tests that perform an upgrade: -`just test-tmt-one test-20-local-upgrade` +```bash +just test-tmt local-upgrade-reboot +``` + +To run a specific test: + +```bash +just test-tmt readonly +``` ### Faster iteration cycles @@ -96,6 +115,26 @@ then you can `cargo b --release` directly in a Fedora 42 container or even on your host system, and then directly run e.g. `./target/release/bootc upgrade` etc. +### Testing with composefs (sealed images) + +To build and test with the experimental composefs backend: + +```bash +# Build a sealed image with auto-generated test Secure Boot keys +just build-sealed + +# Run composefs-specific tests +just test-composefs + +# Validate that composefs digests match between build and install views +# (useful for debugging mtime/metadata issues) +just validate-composefs-digest +``` + +The `build-sealed` target generates test Secure Boot keys in `target/test-secureboot/` +and builds a complete sealed image with UKI. See [experimental-composefs.md](docs/src/experimental-composefs.md) +for more information on sealed images. + ### Debugging via lldb From 1e5ebdc54fab7f4bd07f40d37e1cacbc552aa43b Mon Sep 17 00:00:00 2001 From: Alex Iribarren Date: Fri, 30 Jan 2026 18:15:16 +0100 Subject: [PATCH 24/35] Add AlmaLinux to adopters list Added AlmaLinux (Atomic SIG) as a new adopter Signed-off-by: Alex Iribarren --- ADOPTERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADOPTERS.md b/ADOPTERS.md index 1a5b28b..42d1625 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -9,6 +9,7 @@ |:-|:-|:-|:-|:-| Vendor | Red Hat | 2024 | https://redhat.com | Image Based Linux Vendor | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operating system for your devices +Vendor | AlmaLinux (Atomic SIG) | 2025 | [atomic-desktop](https://github.com/AlmaLinux/atomic-desktop), [atomic-workstation](https://github.com/AlmaLinux/atomic-workstation) | Atomic AlmaLinux desktop respins # bootc Adopters (indirect, via ostree) From a9a23e3e4bd1cae7b58ba9bdf1cd87c4f8034923 Mon Sep 17 00:00:00 2001 From: Joseph Marrero Corchado Date: Wed, 4 Feb 2026 11:00:21 -0500 Subject: [PATCH 25/35] MAINTAINERS: Add Preethi as representative Preethi represents bootc in public forums like Kubecon, RH Summit and our community meetings. Signed-off-by: Joseph Marrero Corchado --- MAINTAINERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 0488a13..2dbfcc7 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -19,3 +19,4 @@ This group can represent the project for administrative and program manager duti | ---- | ---- | ---- | ---- | | Laura Santamaria | [nimbinatus](https://github.com/nimbinatus) | Red Hat | Representative | | Mohan Shash | [mohan-shash](https://github.com/mohan-shash) | Red Hat | Representative | +| Preethi Thomas | [preethit](https://github.com/preethit) | Red Hat | Representative | From 0cba2f086a461d57ad1e7c9877b368c126ff32fa Mon Sep 17 00:00:00 2001 From: "Michael L. Young" Date: Wed, 11 Feb 2026 11:09:24 -0500 Subject: [PATCH 26/35] Add CIQ to the list of adopters of bootc Signed-off-by: Michael L. Young --- ADOPTERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADOPTERS.md b/ADOPTERS.md index 42d1625..3ec85d2 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -10,6 +10,7 @@ Vendor | Red Hat | 2024 | https://redhat.com | Image Based Linux Vendor | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operating system for your devices Vendor | AlmaLinux (Atomic SIG) | 2025 | [atomic-desktop](https://github.com/AlmaLinux/atomic-desktop), [atomic-workstation](https://github.com/AlmaLinux/atomic-workstation) | Atomic AlmaLinux desktop respins +Vendor | CIQ | 2026 | https://ciq.com | Rocky Linux from CIQ (RLC) - Image Based Linux - Standard and Cloud variants # bootc Adopters (indirect, via ostree) From d5d21d5907f80a5040e9809e765a24409025fc96 Mon Sep 17 00:00:00 2001 From: Ziad Khouri Date: Sat, 28 Feb 2026 08:48:26 +0700 Subject: [PATCH 27/35] docs: Add Caligra Workbench to adopters list Signed-off-by: Ziad Khouri --- ADOPTERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADOPTERS.md b/ADOPTERS.md index 3ec85d2..cbf34fd 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -10,6 +10,7 @@ Vendor | Red Hat | 2024 | https://redhat.com | Image Based Linux Vendor | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operating system for your devices Vendor | AlmaLinux (Atomic SIG) | 2025 | [atomic-desktop](https://github.com/AlmaLinux/atomic-desktop), [atomic-workstation](https://github.com/AlmaLinux/atomic-workstation) | Atomic AlmaLinux desktop respins +Vendor | Caligra | 2025 | [workbench](https://caligra.com/workbench/) | An OS designed to accelerate knowledge work Vendor | CIQ | 2026 | https://ciq.com | Rocky Linux from CIQ (RLC) - Image Based Linux - Standard and Cloud variants # bootc Adopters (indirect, via ostree) From c3dd4a92b06a045c9762520aa22877db44b4745f Mon Sep 17 00:00:00 2001 From: mohan-shash <162627980+mohan-shash@users.noreply.github.com> Date: Wed, 4 Mar 2026 18:13:32 -0500 Subject: [PATCH 28/35] Add CODE_OF_CONDUCT.md for CNCF Incubation requirements (#2024) Signed-off-by: Laura Santamaria --- CODE_OF_CONDUCT.md | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..62a5861 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,4 @@ +# Bootc Project Code of Conduct + +The Bootc project has adopted the [CNCF Community Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). +All community members, contributors, and participants in the Bootc project are expected to abide by this Code of Conduct. This includes respectful treatment of everyone, regardless of their background or identity. From 9fb41a9a94aaaa335dcd712366cd47be4548a213 Mon Sep 17 00:00:00 2001 From: Kyle Gospodnetich Date: Fri, 13 Mar 2026 12:15:16 -0700 Subject: [PATCH 29/35] Add Universal Blue vendor entry to ADOPTERS.md Signed-off-by: Kyle Gospodnetich --- ADOPTERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADOPTERS.md b/ADOPTERS.md index cbf34fd..d0c102a 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -12,6 +12,7 @@ Vendor | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operati Vendor | AlmaLinux (Atomic SIG) | 2025 | [atomic-desktop](https://github.com/AlmaLinux/atomic-desktop), [atomic-workstation](https://github.com/AlmaLinux/atomic-workstation) | Atomic AlmaLinux desktop respins Vendor | Caligra | 2025 | [workbench](https://caligra.com/workbench/) | An OS designed to accelerate knowledge work Vendor | CIQ | 2026 | https://ciq.com | Rocky Linux from CIQ (RLC) - Image Based Linux - Standard and Cloud variants +Vendor | Universal Blue (Aurora/Bazzite/Bluefin) | 2024 | https://universal-blue.org/ | Image Based Linux # bootc Adopters (indirect, via ostree) From b5c4d09dcbe0d9f792598c161526b43a74248275 Mon Sep 17 00:00:00 2001 From: Kyle Gospodnetich Date: Fri, 13 Mar 2026 12:17:03 -0700 Subject: [PATCH 30/35] Remove Universal Blue from ostree table Updated the description for Universal Blue to clarify its features. Signed-off-by: Kyle Gospodnetich --- ADOPTERS.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ADOPTERS.md b/ADOPTERS.md index d0c102a..07acb19 100644 --- a/ADOPTERS.md +++ b/ADOPTERS.md @@ -12,7 +12,7 @@ Vendor | HeliumOS | 2024 | https://www.heliumos.org/ | An atomic desktop operati Vendor | AlmaLinux (Atomic SIG) | 2025 | [atomic-desktop](https://github.com/AlmaLinux/atomic-desktop), [atomic-workstation](https://github.com/AlmaLinux/atomic-workstation) | Atomic AlmaLinux desktop respins Vendor | Caligra | 2025 | [workbench](https://caligra.com/workbench/) | An OS designed to accelerate knowledge work Vendor | CIQ | 2026 | https://ciq.com | Rocky Linux from CIQ (RLC) - Image Based Linux - Standard and Cloud variants -Vendor | Universal Blue (Aurora/Bazzite/Bluefin) | 2024 | https://universal-blue.org/ | Image Based Linux +Vendor | Universal Blue (Aurora/Bazzite/Bluefin) | 2024 | https://universal-blue.org/ | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop # bootc Adopters (indirect, via ostree) @@ -30,7 +30,6 @@ is to be the successor to ostree, and it is our aim to seamlessly carry forward | Vendor | Apertis | 2020 | [link](https://apertis.org) | Collaborative OS platform for products | Vendor | Fedora Project | 2021 | [link](https://fedoraproject.org/atomic-desktops/) | An atomic desktop operating system aimed at good support for container-focused workflows | Vendor | Playtron GameOS | 2022 | [link](https://www.playtron.one/) | A video game console OS that has integration with the top PC game stores | -| Vendor | Universal Blue | 2022 | [link](https://universal-blue.org/) | The reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop | Vendor | Fyra Labs | 2024 | [link](https://fyralabs.com) | Bootc powers an experimental variant of Ultramarine Linux ### Adopter Types From cc0bfcf0729f7d5eef55400db2a229f94ea7e01f Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 6 Apr 2026 09:23:04 -0400 Subject: [PATCH 31/35] sysext: Add fast path dev flow For most work on `bootc upgrade` or `bootc switch`, rebuilding the full container image is unnecessary. This adds a fast-path workflow that builds just the bootc binary into a systemd-sysext and overlays it onto /usr in a persistent bcvk VM via virtiofs. For more info see the updated Justfile. There's still some TODOs here - e.g. we need to support running the TMT tests this way, etc. Assisted-by: OpenCode (claude-opus-4-6) Signed-off-by: Colin Walters --- CONTRIBUTING.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 31d217f..85b45d7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -104,6 +104,31 @@ For the local case, check out [cstor-dist](https://github.com/cgwalters/cstor-di Another alternative is mounting via virtiofs (see e.g. [this PR to bcvk](https://github.com/bootc-dev/bcvk/pull/16)). If you're using libvirt, see [this document](https://libvirt.org/kbase/virtiofs.html). +#### Using sysext for fast iteration + +For the fastest development cycle when working on the bootc client +(e.g. `bootc upgrade`, `bootc switch`), you can use the sysext-based +workflow. This builds the bootc binary via a container, shares it into +a persistent VM via virtiofs, and overlays it onto `/usr` using +systemd-sysext (~30s rebuild cycle): + +```bash +# Build sysext and launch a persistent dev VM +just bcvk up + +# After editing code, rebuild and refresh the overlay (~30s) +just bcvk sync + +# SSH into the VM — bootc is your dev build +just bcvk ssh bootc status + +# When done +just bcvk down +``` + +The sysext overlay means `bootc` on the VM's PATH is your dev build. +Run `just bcvk` to list all available commands. + #### Running bootc against a live environment If your development environment host is also a bootc system (e.g. a From d9c87110138c3216fe0038242feb2bdf89384124 Mon Sep 17 00:00:00 2001 From: bootc-dev Bot Date: Fri, 24 Apr 2026 22:07:00 +0000 Subject: [PATCH 32/35] Sync common files from infra repository Synchronized from bootc-dev/infra@fb9e91b161adacd1c0e9144a76b64159c482b92e. Signed-off-by: bootc-dev Bot --- REVIEW.md | 59 +++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 44 insertions(+), 15 deletions(-) diff --git a/REVIEW.md b/REVIEW.md index 80e6f4d..f9ee4d5 100644 --- a/REVIEW.md +++ b/REVIEW.md @@ -90,24 +90,54 @@ follow your reasoning: "Especially grateful for breaking it up into individual commits so I can more easily follow your train of thought." Preparatory refactoring should be separate from behavioral changes. Each commit -should tell a clear story and be reviewable independently. Commit messages should -explain the "why" not just the "what," and use imperative mood ("Add feature" -not "Added feature"). +should tell a clear story and be reviewable independently. Where applicable, +create "prep" commits that could be merged separately from the behavioral change. -### PR Descriptions +### Commit Messages + +Write clear and descriptive commit messages using a `component: Summary` +subject, such as `kernel: Add find API w/correct hyphen-dash equality, add docs`. +Use imperative mood: "Add integration with..." not "Adds integration with...". + +The body of the commit should start with at least one sentence (or paragraph) +describing **why** the change is being made, even for something apparently +trivial. For example a "refactor" commit might have a "why" rationale of just +"Prep for handling X later." A big commit introducing a feature may seem +self-explanatory, but there is often ambient context like "A large-scale Debian +user wanted this" that provides helpful grounding in the motivation. + +If there's a linked tracking issue, often that will contain a more extensive +rationale that doesn't need to be duplicated entirely in the commit message, +but do ensure the commit message has something useful on its own for a rationale. + +Keep it natural and concise. A few sentences of prose explaining the design +intent or the high-level data flow is often good enough. If there's a +non-obvious consequence of the change, call it out briefly (e.g. "Note the +manifest becomes part of the GC root") rather than explaining the full +mechanism. Think about what a reviewer needs to know that may not be obvious +from a skim of the code. + +Do not restate obvious parts of what is already visible in the commit diff: -PRs should link to the issues they address using `Closes:` or `Fixes:` with -full URLs. One reviewer noted: "I edited this issue just now to have -`Closes: ` but let's try to be sure we're doing that kind of thing in -general in the future." +- "Changed function X to call Y" +- Generic `Changes:` sections with bulleted lists of implementation details +- "Files changed" sections — completely redundant with git -Document known limitations and caveats explicitly. When approaches have tradeoffs -or don't fully solve a problem, say so. For complex investigations, use collapsible -`
` sections to include debugging notes without cluttering the main -description. +Implementation details belong in the code documentation. The goal of the +commit message is like a "cover letter" for the change, with a primary +rationale of why the change is being made, alongside a concise summary of +its implementation. -Think about broader implications: "But we'll have this problem across all repos -right?" Consider how your change affects the wider ecosystem. +Another thing that can go in the commit message is brief descriptions +of alternative approaches that were considered and discarded. + +Closes: tags should generally come at the end of the commit message. + +### PR Descriptions + +Generally, just restate the commit message. + +Where it makes sense, it is OK to include additional details though. ### Keeping PRs Current @@ -123,7 +153,6 @@ Do not add `Signed-off-by` lines automatically—these require explicit human action after review. If code was AI-assisted, include an `Assisted-by:` trailer indicating the tool and model used. - ## Architecture and Design ### Workarounds vs Proper Fixes From d583b8e8634147907bc081c3cc8aad80f05141f6 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 6 Apr 2026 17:40:21 -0400 Subject: [PATCH 33/35] docs: Document composefs backend build and test workflows The composefs backend has a multi-dimensional configuration space (variant, bootloader, boot_type, seal_state, filesystem) with non-obvious constraints between them. Add a clear reference table and common workflow examples to CONTRIBUTING.md, and a quick-start cheat sheet to the Justfile header. Assisted-by: OpenCode (Claude Opus 4) Signed-off-by: Colin Walters --- CONTRIBUTING.md | 65 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 56 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 85b45d7..a189e51 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -140,25 +140,72 @@ then you can `cargo b --release` directly in a Fedora 42 container or even on your host system, and then directly run e.g. `./target/release/bootc upgrade` etc. -### Testing with composefs (sealed images) +### Building and testing with the composefs backend -To build and test with the experimental composefs backend: +bootc has two storage backends: `ostree` (default, production) and `composefs` +(experimental). The composefs backend has several axes of configuration: + +| Variable | Values | Notes | +|---|---|---| +| `variant` | `ostree`, `composefs` | Storage backend | +| `bootloader` | `grub`, `systemd` | systemd-boot required for UKI | +| `boot_type` | `bls`, `uki` | UKI embeds the composefs digest | +| `seal_state` | `unsealed`, `sealed` | Sealed signs the UKI for Secure Boot | +| `filesystem` | `ext4`, `btrfs`, `xfs` | xfs lacks fsverity, incompatible with sealed | + +These are controlled via `BOOTC_`-prefixed environment variables. +Using environment variables (rather than `just` command-line overrides) +is recommended because they persist across commands in the same shell +session — so `just build` followed by `just test-tmt` will use the +same configuration: ```bash -# Build a sealed image with auto-generated test Secure Boot keys +# Set up a composefs development session +export BOOTC_variant=composefs +export BOOTC_bootloader=systemd +# Now all just targets use these settings: +just build +just test-tmt readonly +just test-container +``` + +The constraints are: + +- `sealed` requires `boot_type=uki` (the digest lives in the UKI cmdline) +- `sealed` requires `filesystem` with fsverity support (`ext4` or `btrfs`) +- `uki` requires `bootloader=systemd` + +Common workflows: + +```bash +# Simplest composefs build (unsealed, grub, BLS, ext4) +export BOOTC_variant=composefs +just build + +# Composefs with systemd-boot +export BOOTC_variant=composefs BOOTC_bootloader=systemd +just build + +# Fully sealed image (systemd-boot + signed UKI + Secure Boot) +# This is the most common composefs dev workflow: just build-sealed -# Run composefs-specific tests -just test-composefs +# Run composefs integration tests (all four params are required) +just test-composefs systemd ext4 bls unsealed + +# Run sealed UKI tests +just test-composefs systemd ext4 uki sealed -# Validate that composefs digests match between build and install views +# Validate composefs digests match between build and install views # (useful for debugging mtime/metadata issues) just validate-composefs-digest ``` -The `build-sealed` target generates test Secure Boot keys in `target/test-secureboot/` -and builds a complete sealed image with UKI. See [experimental-composefs.md](docs/src/experimental-composefs.md) -for more information on sealed images. +The `build-sealed` target generates test Secure Boot keys in +`target/test-secureboot/` and builds a complete sealed image with all +the sealed composefs settings. See +[experimental-composefs.md](docs/src/experimental-composefs.md) for +more information on sealed images. ### Debugging via lldb From 85f9e856f7cacd5f0ca587f5ee747f8f9944fcd9 Mon Sep 17 00:00:00 2001 From: bootc-dev Bot Date: Mon, 11 May 2026 04:53:46 +0000 Subject: [PATCH 34/35] Sync common files from infra repository Synchronized from bootc-dev/infra@ff66c1c724faeb83b5cd2af36d9a5d2129ecf95a. Signed-off-by: bootc-dev Bot --- REVIEW.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/REVIEW.md b/REVIEW.md index f9ee4d5..3c1d690 100644 --- a/REVIEW.md +++ b/REVIEW.md @@ -139,6 +139,20 @@ Generally, just restate the commit message. Where it makes sense, it is OK to include additional details though. +### Further changes on top of existing commits + +If you have followup fixes (whether that's part of a local loop or +as part of addressing PR review), it is generally encouraged to *squash* +the fixes into the prior commit. Do not create generically-named "Update " commits +or "Address review feedback" or "Fix cargo fmt" commits. + +This applies equally when an AI tool (e.g. Gemini, Copilot) suggests a +change via a review comment — applying the suggestion creates a new commit +with an auto-generated subject. That commit should be squashed before the +PR is merged. + +In other words either a commit "stands alone" with its own rationale or it doesn't. + ### Keeping PRs Current Keep PRs rebased on main. When CI failures are fixed in other PRs, rebase to From eb0d12af629f83ad99b9fb913e6a92136e2e7425 Mon Sep 17 00:00:00 2001 From: Joseph Marrero Corchado Date: Mon, 1 Jun 2026 11:08:06 -0400 Subject: [PATCH 35/35] MAINTAINERS: Add Mark Russell. Signed-off-by: Joseph Marrero Corchado --- MAINTAINERS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 2dbfcc7..f0b9f94 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -20,3 +20,4 @@ This group can represent the project for administrative and program manager duti | Laura Santamaria | [nimbinatus](https://github.com/nimbinatus) | Red Hat | Representative | | Mohan Shash | [mohan-shash](https://github.com/mohan-shash) | Red Hat | Representative | | Preethi Thomas | [preethit](https://github.com/preethit) | Red Hat | Representative | +| Mark Russell | [marrusl](https://github.com/marrusl) | Red Hat | Representative |