Add a struct to store changes made to a blueprint. Each change contains
a commit which is a hex string based off of an sha1 hash, a message
describing the change, a revision which will usually be null, a
timestamp, and the blueprint at the time of the change.
Introduce the `distro` package, which contains an interface for OS
implementations. Its main purpose is to convert a blueprint to a
distro-specific pipeline.
Also introduce the `distro/fedora30` package. It is the first
implementation of the distro interface. Most of its code has been copied
with minimal modifications from the blueprint package.
The `blueprint` package is now back to serving a single purpose:
representing a weldr blueprint. It does not depend on the `pipeline`
package anymore.
Change osbuild-composer and osbuild-pipeline to use the new API,
hard-coding "fedora-30". This looks a bit weird now, but is the same
behavior as before.
All test cases now also take an "distro" key in the "compose" object.
These tests (will) test more than just image-info: they'll take a
blueprint, verify that `osbuild-pipeline` generates the correct
pipeline, run osbuild with that pipeline and verify that the resulting
image has the expected image-info output.
This change only includes the latter half (i.e., only moves the already
existing tests).
Also drop python's unittest. It was hard to control output (important
for quickly spotting failures and to make travis happy). This introduces
test/run, which runs all test cases in test/cases or the ones given on
the command line.
When a failure occurs, it prints a diff of the actual and the expected
image info.
The main difference (according to image-info) is an additional package
containing a gpg key which was used to verify packages. The one
generated by lorax-composer doesn't have this, because it doesn't verify
signatures.
Also, lorax generates an image with a separate /boot partition. This is
not yet addressed here, because osbuild doesn't support it yet.
The main difference (according to `rpm -qa`) is an additional package
containing a gpg key which was used to verify packages. The one
generated by lorax-composer doesn't have this, because it doesn't verify
signatures.
The main difference (according to image-info) is an additional package
containing a gpg key which was used to verify packages. The one
generated by lorax-composer doesn't have this, because it doesn't verify
signatures.
Also, lorax generates an image with a separate /boot partition. This is
not yet addressed here, because osbuild doesn't support it yet.
The main difference (according to image-info) is an additional package
containing a gpg key which was used to verify packages. The one
generated by lorax-composer doesn't have this, because it doesn't verify
signatures.
A test case is now expressed purely by dropping in a json document in
`tools/test_image_info/pipelines`. It should contain the input compose
(output format and blueprint) as well as the expected pipeline. All the
existing tests are moved over to this format.
This shares the same infrastructure as the image tests, ideally we want
to run the blueprint tests and the image tests against the same pipelines.
For now, test cases are skipped from the blueprint tests if they do not
contain a 'compose' section, and from the image tests if they do not
cotain an 'expected' section. In the future we may want to make both
mandatory.
Signed-off-by: Tom Gundersen <teg@jklm.no>
List of currently unsupported ones:
- [[repos.git]]
- [customizations.kernel]
- [[groups]]
- [[packages]] and [[modules]]
Some of customizations have unimplemented behaviour, see TODOs
Use the autogenerated test framework from VSCode (with minor fixes to
make them compile).
As we do not yet support customizations in blueprint, all the tests are
trivial.
I was not entirely sure about the best way to encode the wanted pipeline
output. I currently represent it as a JSON string and unmarshal it into
the object to compare with.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Each output type will have its own translator from a blueprint to
a pipeline.
In the future, we may also want to distinguish between different
base distributions and architectures, but for now we keep it
simple and hardcode to a given one.
Some placeholder output formats are added, these have not been
tested or reserached, but are included to show how the it will
all fit together.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This will contain all the translation logic from blueprints to pipelines,
which will constitute the main part of composer, so let's separate that
out from the API.
Signed-off-by: Tom Gundersen <teg@jklm.no>
