system_resolver is created based on loaded configuration, which could
avoid calls like `GenericResolver.create(conf)` repeatedly in the code.
However, if some cases need to create a specific resolver explicitly,
`GenericResolver.create` could be called with addition argument, for
example db or mbs is passed to argument backend in tests.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
During I'm reading through the code base to learn MBS, I found out some
typos and minor issues in some other docstrings, and I also found some
docstrings with extra informative description could make it easier to
understand the code.
Signed-off-by: Chenxiong Qi <cqi@redhat.com>
This bug was reported by @nphilipp here https://bodhi.fedoraproject.org/updates/FEDORA-2018-c9c3a37d96
The issue is that the `record_filtered_rpms` method returns a new xmd
buildrequires block, but whole buildrequires entries were omitted in the return
value for local builds. This one-liner includes them again.
If a module has filters set and it buildrequires itself, issues occur
during component reuse. In that event, the filtered RPMs from the
previous module build will not be available in the buildroot because the NVRs
in the filters will match the RPMs from the reused component.
Co-authored-by: Jan Kaluza <jkaluza@redhat.com>
This reverts commit 8173040ea6. Since it didn't
provide any real benefit after talking with sgallagh, it seems like we'd better
off not introduce more risk to the next deployment.
The name from the NVR and the name from the component may be different based on
the macros being used as part of the build. SCLs are a great example of this.
MBS has been using the libmodulemd API incorrectly by assuming that
methods like `get_rpm_components` return the actual object in memory
and not a copy. This has been true but wasn't something sgallagh
intended. We found this out after he had me test his new version of
libmodulemd. This PR removes those assumptions.
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
Updated PR according to review.
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
Searching by multiple koji tags + tests
Signed-off-by: Martin Curlej <mcurlej@redhat.com>
We can't rely on matching name-stream to distinguish which module is
currently being built as modules can buildrequire older versions of
the same module-stream.
Fixes#954
1. Changed ModuleBuild's context property to db column, it's
non-nullable and default value is '00000000' to keep it consistent
with previous behaviour.
2. Changed ModuleBuild.contexts_from_mmd to return a tuple of
(ref_build_context, build_context, runtime_context, context).
3. Updated tests affected by this change.
koji now supports tags with max length of 256, we can use
more informative tag name instead of the hash one.
The new format of koji tag name is:
module-<name>-<stream>-<version>-<context>
However when the generated tag's length > (256 - len('build')), we
fallback to the old way of name in hash format (module-<hash>).
In this change, koji tag is always generated from MBS itself, even
with pdc resolver.
FIXES: #918#925
