Lorax is a set of tools used to create bootable images.
395c4a4b7f
- test against already existing git repository
- test commit_recipe_file() handling of IOError
- update tests for commit_recipe_directory()
- add asserts on the existing test. Not raising an exception
isn't enough!
- add test which exercises the method under test while it handles
exceptions raised by other methods
- test for list_commits() when the underlying calls fail to convert
timestamp
- test for find_name() when `name' is not on the list
- tests for get_revision_from_tag()
|
||
|---|---|---|
| docs | ||
| etc | ||
| rel-eng | ||
| share | ||
| src | ||
| systemd | ||
| tests | ||
| utils | ||
| .coveragerc | ||
| .gitignore | ||
| .travis.yml | ||
| ANNOUNCE | ||
| AUTHORS | ||
| COPYING | ||
| Dockerfile.test | ||
| epel.repo | ||
| lorax.spec | ||
| Makefile | ||
| POLICY | ||
| README | ||
| README.livemedia-creator | ||
| README.product | ||
| setup.py | ||
| TODO | ||
I am the Lorax. I speak for the trees [and images].
Tree building tools such as pungi and revisor rely on 'buildinstall' in
anaconda/scripts/ to produce the boot images and other such control files
in the final tree. The existing buildinstall scripts written in a mix of
bash and Python are unmaintainable. Lorax is an attempt to replace them
with something more flexible.
EXISTING WORKFLOW:
pungi and other tools call scripts/buildinstall, which in turn call other
scripts to do the image building and data generation. Here's how it
currently looks:
-> buildinstall
* process command line options
* write temporary yum.conf to point to correct repo
* find anaconda release RPM
* unpack RPM, pull in those versions of upd-instroot, mk-images,
maketreeinfo.py, makestamp.py, and buildinstall
-> call upd-instroot
-> call maketreeinfo.py
-> call mk-images (which figures out which mk-images.ARCH to call)
-> call makestamp.py
* clean up
PROBLEMS:
The existing workflow presents some problems with maintaining the scripts.
First, almost all knowledge of what goes in to the stage 1 and stage 2
images lives in upd-instroot. The mk-images* scripts copy things from the
root created by upd-instroot in order to build the stage 1 image, though
it's not completely clear from reading the scripts.
NEW IDEAS:
Create a new central driver with all information living in Python modules.
Configuration files will provide the knowledge previously contained in the
upd-instroot and mk-images* scripts.
--
David Cantrell <dcantrell@redhat.com>