6695294a29
The way that runners were designed is the following: For each distro we have a specific runner. In case a new version of the distro can use the previous runner, we just create a symlink. In case a new distro version needs adjustments, the runner is copied and adjusted. This is a very clean and obvious design. There is one big drawback: For each new distribution a symlink must be created before it can be used. For Fedora that should ideally happen when it is branched; and this will, ipso facto, always be a symlink since at the time of the branching the new distro is the old distro. But at this very moment osbuild will be broken since it does not contain the new runner; the only way to prevent this is to create the corresponding new runner before the distro is branched, where it then must be a symlink too. This very much suggest that instead of the explicit symlink, which does not /that/ much clarity, the existing "old" runner should just work for the new distribution. This commit implements the logic to do just that: all existing runners are parsed into a distro and version tuple and then, given a specific requested distro, the best matching one is return. |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| assemblers | ||
| data | ||
| devices | ||
| docs | ||
| inputs | ||
| mounts | ||
| osbuild | ||
| runners | ||
| schemas | ||
| schutzbot | ||
| selinux | ||
| sources | ||
| stages | ||
| test | ||
| tools | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mypy.ini | ||
| .packit.yaml | ||
| .travis.yml | ||
| LICENSE | ||
| Makefile | ||
| osbuild.spec | ||
| README.md | ||
| requirements.txt | ||
| samples | ||
| Schutzfile | ||
| setup.cfg | ||
| setup.py | ||
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
- IRC: #osbuild on Libera.Chat
- Changelog: https://github.com/osbuild/osbuild/releases
Contributing
Please refer to the developer guide to learn about our workflow, code style and more.
Requirements
The requirements for this project are:
bubblewrap >= 0.4.0python >= 3.7
Additionally, the built-in stages require:
bash >= 5.0coreutils >= 8.31curl >= 7.68qemu-img >= 4.2.0rpm >= 4.15tar >= 1.32util-linux >= 235skopeo
At build-time, the following software is required:
python-docutils >= 0.13pkg-config >= 0.29
Testing requires additional software:
pytest
Install
Installing osbuild requires to not only install the osbuild module, but also
additional artifacts such as tools (i.e: osbuild-mpp) sources, stages, schemas
and SELinux policies.
For this reason, doing an installation from source is not trivial and the easier way to install it is to create the set of RPMs that contain all these components.
This can be done with the rpm make target, i.e:
make rpm
A set of RPMs will be created in the ./rpmbuild/RPMS/noarch/ directory and can
be installed in the system using the distribution package manager, i.e:
sudo dnf install ./rpmbuild/RPMS/noarch/*.rpm
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.