Now we have good separation between runtime and buildtime dependencies:
If mmd has context, it is built artefact which supposed to have only one
dependency entry, we create solvable with real arch for it. Otherwise we
create multiple solvables with "src" arch.
In "src" solvables, "context" is a number which represents index in
dependencies array.
Stream is not included anymore in "evr" because it's incomparable.
Version is not included anymore in "name" because it's there just for
comparison, nothing more (it's not different module-stream).
As a side, add_requires/add_conflicts/add_provides were replaced with
non-deprecated add_deparray method.
With all this, we are ready to handle MMDs which have multiple elements
in dependencies (modulemd v2).
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Previous version was assuming that number of alternatives is static
which is wrong, they can be appearing depending on solvables.
Also it was checking even impossible combinations (due to using
itertools.product).
Now we check only real possibilities.
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
This fixes an issue that occurs when someone submits a module build and most of its components
get reused and the poller just so happens to try to resume the build.
I ran into issues on CentOS CI where fake Koji build messages were getting
one ID but the task_id for the component in the database was getting
another. Making the build_id random and not tied to the class seems to
resolve that issue.
It seems that there is a bug with the Flask test client when submitting a tuple of
file path and content, that incorrectly sets the filename to be the first line of
the file contents instead of the actual filename. We should eventually investigate
this and report a bug or provide a patch.
This is a bit of a stab in the dark.
In some environments, our build.log files have little to no contents. This
might be because we don't have an explicit log level set, but maybe not.
