depsolve: add modules support
#1163
Conversation
Since the modularity PR landed in `osbuild` the depsolve result now contains a `modules` key with data if modules were resolved. Add the appropriate structures to the depsolve result, without propagating them into rpmmd for now. Also adds a quick test for the internal `depsolveResult` type deserialization to ensure it understands some JSON serialized data that contains a `modules` key. Signed-off-by: Simon de Vlieger <supakeen@redhat.com>
supakeen
force-pushed
the
module-field-in-depsolve
branch
from
9ac21b0 to
48ef775
Compare
Correct; this commit is purely to let images be able to understand the new depsolve responses, the rest will be built on top of it. This is to unblock the integration CI that uses Should the pinned osbuild ref be part of this PR? |
I don't think it will make any difference, so not a blocker. |
| func TestDepsolveResultWithModulesKey(t *testing.T) { | ||
| // quick test that verifies that `depsolveResult` understands JSON that contains | ||
| // a `modules` key | ||
| data := []byte(`{"modules": {}}`) |
There was a problem hiding this comment.
I wonder how much value this test adds as it is.I personally would either omit it or expand it to cover some real world module example (in the sense of tests as documentation). Fine in a followup of course if we should get this in ASAP
There was a problem hiding this comment.
I'm going to prefer to do that as a followup. I mostly used this test case to have a very minor smoke test that the depsolver no longer breaks when a modules key is present. Because testing it otherwise is kind-of-cumbersome (unreleased osbuild depsolver has to be somewhere images likes it).
I'll be updating to an idiom much like what you implemented in osbuild in osbuild/osbuild#1993
Since the modularity PR osbuild/osbuild#1933 landed in
osbuildthe depsolve result now contains amoduleskey with data if modules were resolved.Add the appropriate structures to the depsolve result, without propagating them into rpmmd for now.
Also adds a quick test for the internal
depsolveResulttype deserialization to ensure it understands some JSON serialized data that contains amoduleskey.This PR will serve as the basis for #1095 where the types will be propagated to rpmmd and the stage will be implemented; but this one is important to unblock our CI as everything now fails on the unexpected field.
Note that, as opposed to the nevra field on packages which was a big red herring today; this field is actually expected to be added. Hence we can't just remove it from the depsolve response. This also means that the DNF JSON version will need to be bumped; even though we didn't want to do that (cc: @ondrejbudai). See osbuild/osbuild#1992 for that bump.
When this commit is to be depended on by
osbuild-composerandimage-builder-cliwe will likely need to depend on the new API version as well if I understand correctly (cc @thozza).