We want to run stages and other scripts inside of the nspawn containers
we use to build pipelines. Since our pipelines are meant to be
self-contained, this should imply that the build-root must have osbuild
installed. However, this has not been the case so far for several
reasons including:
1. OSBuild is not packaged for all the build-roots we want to support
and thus we have the chicken-and-egg problem.
2. During testing and development, we want to support using a local
`libdir`.
3. We already provide an API to the container. Importing scripts from
the outside just makes this API bigger, but does not change the
fact that build-roots are not self-contained. Same is true for the
running kernel, and probably much more..
With all this in mind, our strategy probably still is to eventually
package osbuild for the build-root. This would significantly reduce our
API exposure, points-of-failure, and host-reliance. However, this switch
might still be some weeks out.
With this in mind, though, we can expect the ideal setup to have a full
osbuild available in the build-root. Hence, any script we import so far
should be able to access the entire `libdir`. This commit unifies the
libdir handling by installing the symlinks into `libdir` and providing
a single bind-mount of the module-path into `libdir`.
We can always decide to scratch that in the future when we scratch the
libdir-import from the host-root. Until then, I believe this commit
nicely unifies the way we import the module both in a local checkout as
well as in the container.
|
||
|---|---|---|
| .github/workflows | ||
| assemblers | ||
| docs | ||
| jenkins | ||
| osbuild | ||
| runners | ||
| samples | ||
| schemas | ||
| sources | ||
| stages | ||
| test | ||
| .editorconfig | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| LICENSE | ||
| Makefile | ||
| NEWS.md | ||
| osbuild.spec | ||
| README.md | ||
| setup.py | ||
| tree-diff | ||
OSBuild
Build-Pipelines for Operating System Artifacts
OSBuild is a pipeline-based build system for operating system artifacts. It defines a universal pipeline description and a build system to execute them, producing artifacts like operating system images, working towards an image build pipeline that is more comprehensible, reproducible, and extendable.
See the osbuild(1) man-page for details on how to run osbuild, the definition
of the pipeline description, and more.
Project
- Website: https://www.osbuild.org
- Bug Tracker: https://github.com/osbuild/osbuild/issues
Requirements
The requirements for this project are:
python >= 3.7systemd-nspawn >= 244
Additionally, the built-in stages require:
bash >= 5.0coreutils >= 8.31curl >= 7.68qemu-img >= 4.2.0rpm >= 4.15tar >= 1.32util-linux >= 235
At build-time, the following software is required:
python-docutils >= 0.13pkg-config >= 0.29
Build
The standard python package system is used. Consult upstream documentation for detailed help. In most situations the following commands are sufficient to build and install from source:
python setup.py build
python setup.py install --skip-build --root=/
The man-pages require python-docutils and can be built via:
rst2man docs/<input-file>.rst <output-file>
Repository:
- web: https://github.com/osbuild/osbuild
- https:
https://github.com/osbuild/osbuild.git - ssh:
git@github.com:osbuild/osbuild.git
License:
- Apache-2.0
- See LICENSE file for details.