42a365d12f
Do not automatically commit the last stage of the pipeline to the store. The last stage is most likely not what should be cached, because it will contain all the individual customization and thus be very likely different for different users. Instead, the dnf or rpm stages have a higher chance of being the same and thus are better candidates for caching. Technically this change is done via two big changes that build upon new features introduces in the previous commits, most notably the copy on write semantics of Object and that input/output is being done via `objectstore.Object` instead of plain paths. The first of the two big changes is to create one new `Object` at the beginning of `pipeline.run` and use that, in write mode via `Object.write` across invocations of `stage.run` calls, with checkpoints being created after each stage on demand. The very same `Object` is then used in read mode via `Object.read` as the input tree for the Assembler. After the assembler is done the resulting image/tree is manually committed to the store. The other big change is to remove the `ObjectStore.commit` call from the `ObjectStore.new` method and thus the automatic commit after the last stage is gone. NB: since the build tree is being retrieved in `get_buildtree` from the store, a checkpoint for the last stage of the build pipeline is forced for now. Future commits will refactor will do away with that forced commit as well. Change osbuildtest.TestCase to always create a checkpoint at the final tree (the last stage of the pipeline), since tests need it to check the tree contents. |
||
|---|---|---|
| .. | ||
| os-release | ||
| pipelines | ||
| sources_tests/org.osbuild.files | ||
| stages_tests | ||
| testing-rpms | ||
| .gitignore | ||
| __init__.py | ||
| osbuildtest.py | ||
| README.md | ||
| test_assemblers.py | ||
| test_boot.py | ||
| test_objectstore.py | ||
| test_osbuild.py | ||
| test_osrelease.py | ||
| test_sources.py | ||
| test_stageinfo.py | ||
| test_stages.py | ||
Setup
To run the tests in vagrant virtual machine, please follow this tutorial: https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html
(run also sudo systemctl start libvirtd)
Using Vagrant
To start a Vagrant box by hand, run vagrant up in this directory. To stop and remove all volumes run vagrant destroy again in this directory.
Troubleshooting
In case you accidentally deleted .vagrant directory, you can use some of these commands in order to get rid of running instance:
$ virsh list # this should display test_default
$ virsh managedsave-remove test_default
$ virsh undefine test_default
# or using vagrant cli tool
$ vagrant global-status
$ vagrant destroy <id>
$ vagrant global-status --prune