The original Pungi code, on which MBS code is based on, always passed only RPMs
with valid architectures to further decide if their subset should end up in a
final modulemd file.
In MBS, we pass RPMs with all architecture and there was no code to actually filter
out the RPMs which are from architectures which should never end up in a final MMD.
This commit checks that RPMs for completely different architectures will never
be considered to be included in a final MMD.
The build steps assume that the the repository for the build is non-modular,
so after the final createrepo is run with include_module_yaml=True, it's
impossible to repeat a build steps. Running mock -c <failed_config> build is
quite useful for debugging a failed build (even though it's hard to find the
right config) - skipping the final createrepo step for failed module builds
makes it work as expected.
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>
The list of arches we compare against should not include multilib
arches. Otherwise excluding does not behave correctly.
Example:
A build has ExcludeArch: i686 (because it only works on 64 bit arches).
A noarch package is built there, but it would be excluded from x86_64.
Relates: https://pagure.io/pungi/pull-request/1050
Signed-off-by: Lubomír Sedlář <lsedlar@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>
First, rename LocalBuilder to SRPMBuilder. Reading the manpage for mock tells
me that the `--rebuild` option is specifically for rebuilding a given srpm.
The class was just named poorly (imo).
Second, change the type detection. The bug I'm trying to fix is if you try to
pass a string for the `repository:` in your modulemd like
`file:///home/user/repos/libfoo/`. The old logic here would assume that it is
an srpm since it didn't start with "git" or "http", but that's not correct. We
have people who want to experiment with building modules with components that
are not publicly accessible over the network - which are only local. This
change allows that.
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 addresses an issue when a module contains builds that have different
names in their NVR than the component name in MBS. This happens with
SCLs for instance. MBS wouldn't be able to find the component to mark
as tagged in the database since it was searching by the wrong name, so the
build would just stall. This uses the NVR now to find the correct build
in the database.
Previously MBS configured all Koji build tags with
repo_include_all=True extra option. But for some modules it was
desired to be able to have tags with repo_include_all=False.
Fixes#957
No reason to hide module context from the consumers, plus it's useful to
keep it in the DISTTAG tag (not to be confused with the %{dist} tag) for
tracking.
The %{disttag} feature will do nothing until RPM supports it. This is
planned in 4.14.2.
See https://bugzilla.redhat.com/show_bug.cgi?id=1596192.
Signed-off-by: Petr Šabata <contyk@redhat.com>
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>
I discovered that local builds have been broken by recent (good) changes in
dnf. At the end of every batch, we regenerate the local repo with createrepo
and we also call modifyrepo to include the modulemd file as we progress. This
was added in #467.
What we really want, is for the modulemd file to be present at the *end* of the
build.
Recently, dnf started respecting the modulemd file natively, such that builds
we built in batch0 would not show up in batch1. They would be present in the
repo, but they would be marked as belonging to a module which was not enabled,
and so could not be pulled in. Every module build would fail because
module-srpm-macros was in a disabled module (the module being built at the
time).
This change makes it so that the module metadata is only added to the repo at
the very end of the build. I moved it into a `finalize` method on the builder
which the copr builder was using, and for symmetry's sake I moved the koji
content generator code to the same method on that builder.
There was a circular import issue to solve between the koji module builder and
the koji content generator modules that generated a larger diff, but is mostly
cosmetic and mock changes.
Commit 42aef7d5d2 moved the macros installed by module-build-macros
from %_rpmconfdir (which is unaffected by %_prefix) to %_sysconfdir/rpm
(which follows %_prefix). This interacts badly with the Flatpak module
macros which change %_prefix to /app - when flatpak-rpm-macros is
in the buildroot while module-build-macros is built, module-build-macros
installs its macros to /app and they aren't found when building the
rest of the packages in the module.
Hardcoding /etc rather than using %_sysconfdir fixes this.
The built RPM artifacts were being added to the components list (the
RPMs to build) instead of the proper artifacts section. Also, they
need to be in NEVRA format, so use 'rpm -qf' to query the epochs from
the built artifacts.
