ba6918f945
The best practice for creating a pipeline should be to include at least one level of build-pipelines. This makes sure that the tools used to generate the target image are well-defined. In principle one could add several layers, though in pracite, one would hope that the envinment used to build the buildroot does not affect the final image (and as we anyway cannot recurr indefinitely, we fall back to simply using the host system in this case). This only makes sense, if the contents of the host system truly does not affect the generated image, and as such we do not include any information about the host when computing the hash that identifies a pipeline. In fact, any image could be used in its place, as long as the required tools are present. This commit takes advantage of that fact. Rather than run a pipeline with the host as the build root, take a second pipeline to generate the buildroot, but do not include this when computing the pipeline id (so it is different from simply editing the original JSON). This is necessary so we can use the same pipelines on significantly different host systems (run with different --bulid-pipeline arguments). In particular, it allows our test pipelines that generate f30 images to be run unmodified on Travis (which runs Ubuntu). Signed-off-by: Tom Gundersen <teg@jklm.no> |
||
|---|---|---|
| assemblers | ||
| osbuild | ||
| samples | ||
| stages | ||
| test | ||
| .gitignore | ||
| .packit.yaml | ||
| .pylintrc | ||
| .travis.yml | ||
| LICENSE | ||
| Makefile | ||
| MANIFEST.in | ||
| osbuild-run | ||
| osbuild.spec | ||
| README.md | ||
| setup.py | ||
osbuild
A build system for operating system images, working towards an image build pipeline that's more comprehensible, reproducible, and extendable.
Pipelines
The build process for an image is described by a pipeline. Each stage in a pipeline is a program that, given some configuration, modifies a file system tree. Finally, an assembler takes a filesystem tree, and assembles it into an image. Pipelines are defined as JSON files like this one:
{
"name": "Example Image",
"stages": [
{
"name": "org.osbuild.dnf",
"options": {
"releasever": "30",
"repos": {
"fedora": {
"name": "Fedora",
"metalink": "https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch",
"gpgkey": "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch"
}
},
"packages": [ "@Core", "grub2-pc", "httpd" ]
}
},
{
"name": "org.osbuild.systemd",
"options": {
"enabled_services": [ "httpd" ]
}
},
{
"name": "org.osbuild.grub2",
"options": {
"root_fs_uuid": "76a22bf4-f153-4541-b6c7-0332c0dfaeac"
}
}
],
"assembler": {
"name": "io.weldr.qcow2",
"options": {
"filename": "example.qcow2",
"root_fs_uuid": "76a22bf4-f153-4541-b6c7-0332c0dfaeac"
}
}
}
osbuild runs each of the stages in turn, isolating them from the host and
from each other, with the exception that they all operate on the same
filesystem-tree. The assembler is similarly isolated, and given the same
tree, in read-only mode and assembles it into an image without altering
its contents.
The filesystem tree produced by the final stage of a pipeline, is named and optionally saved to be reused as the base for future pipelines.
Each stage is passed the (appended) options object as JSON over stdin.
The above pipeline has no base and produces a qcow2 image.
Running
usage: python3 -m osbuild [-h] [--store DIRECTORY] [-l DIRECTORY] -o DIRECTORY
PIPELINE
Build operating system images
positional arguments:
PIPELINE json file containing the pipeline that should be built
optional arguments:
-h, --help show this help message and exit
--store DIRECTORY the directory where intermediary os trees are stored
-l DIRECTORY, --libdir DIRECTORY
the directory containing stages, assemblers, and the
osbuild library
required named arguments:
-o DIRECTORY, --output DIRECTORY
provide the empty DIRECTORY as output argument to the
last stage