-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
examples,tests: add new test_against_images_ref.py
test
#188
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<3 seems like some of the manifest names don't match what's expected in the testcase but that should be a minor fix.
Thank you! Yeah, it also looks like "yaml.dump()" is not generating yamllint clean yaml :( [edit: https://github.com/yaml/pyyaml/issues/234#issuecomment-765894586 is a workaround but we still run into yamllint errors because the lines are too long] |
This commit adds the infrastructure to test that a manifest generated by the `images` library is identical to the equivalent version generated via otk. As a first step it adds the centos-9-x86_64-qcow2 manifest.
This commit adds otk manifests based on the "images" library reference images.
This commit adds otk manifests based on the "images" library reference images.
a45d665
to
a84b65c
Compare
a84b65c
to
33a616e
Compare
This PR adds a new test that uses the
images
library to generate reference manifests and then compares the output of an otk run against the reference image. This allows us to refactor theotk
images and always be confident that the result matches what "images" produces.It also converts all the examples to be just "verbatim" versions of the images library result so that it can be a useful starting point to refactor them.
Note that currently the reference manifests are part of the repository for convenience. It would be nicer to generate them on the fly but that is hard(er), see the comments in the code.
Note also that we most likely will have to do something about the "{boot,root}_fs_uuid" in the reference images as they will not match with the ones generated by
otk-gen-partition-table
as the calls intorand
are in a different order yielding predictable but different result between the two. We can cross this bridge when we reach it though and it's fairly simple (or exclude at the diff level).When we add the
dnfjson
external we will need to teach it to generate fake urls/shas just likegen-manifests
so that we can compare the results of a real run.The next steps should be to extract the common pieces into a nice structure (i.e. build #169 on top of this one) and integrate the externals (i.e. start with partition, c.f. #186)
[clean split out from https://github.com//pull/186]