particle-os/debian-bootc-base-images
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

whitespace changes to appease downstream CI

Browse source 
The prow/validate job does some various whitespace checks and
was complaining about these so I guess I'll try to make it happy:

```
 [+] Found files with whitespace at the end of line
./fedora-coreos-config/fedora-bootc/.gitlab-ci.yml
./fedora-coreos-config/fedora-bootc/bootc-base-imagectl.md
./fedora-coreos-config/fedora-bootc/fedora-iot.yaml
./fedora-coreos-config/fedora-bootc/iot/manifest.yaml

[+] Found files with missing empty line at end of file
./fedora-coreos-config/fedora-bootc/bootc-base-imagectl
./fedora-coreos-config/fedora-bootc/fedora-iot.yaml
./fedora-coreos-config/fedora-bootc/iot/manifest.yaml
```
This commit is contained in:
Dusty Mabe 2025-05-09 12:52:16 -04:00
parent e7cf60c183
commit ef5e95d5bd
No known key found for this signature in database
GPG key ID: 3302DBD73952E671
5 changed files with 9 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

6
bootc-base-imagectl.md
View file

@ -90,7 +90,7 @@ and downloaded by clients, even if the content didn't actually change.
The `bootc-base-imagectl rechunk` command fixes all of these issues
by taking an input container, operates on its final merged filesystem
tree (hence removed/overridden files are handled), and then splits it up
(currently based on the RPM database) into separate layers (tarballs).
(currently based on the RPM database) into separate layers (tarballs).
Further, because bootc uses OSTree today, and OSTree canonializes all timestamps
to zero on the client side, this tool does that at build time.
@ -104,7 +104,7 @@ can be selected by passing `--manifest` to `build-rootfs`.
The current implementation uses `rpm-ostree` on a manifest (treefile)
embedded in the container image itself. These manifests are not intended
to be editable directly.
to be editable directly.
To emphasize: the implementation of this command (especially the configuration
files that it reads) are subject to change.
@ -113,7 +113,7 @@ files that it reads) are subject to change.
The build tooling is designed to support "cross builds"; the
repository root could e.g. be CentOS Stream 10, while the
builder root is Fedora or RHEL, etc.
builder root is Fedora or RHEL, etc.
In other words, one given base image can be used as a "builder" to produce another
using different RPMs.