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.
If the user redefines %_sourcedir in ~/.rpmmacros, `mbs-build local`
will fail trying to build module-build-macros otherwise because rpmbuild
will look for sources -- macros.modules -- in the wrong place.
This was introduced months ago, but we never hit it. I just saw it in
the error logs.
It looks like the call to `session.untaggedBuilds` expects a `name`
argument, but `session.listTagged` does *not*.
* 9c875ce Do not try to rebuild the module-build-macros when it already exists in buildroot.
* 7e57432 Use Koji multicall when tagging builds. Do not query Koji to get the status of builds which we are reusing from previous module build.
* 47c4363Fix#467 - Inject modules.yaml to mock repository
* eaeaf29 unused method
* 6412a7f use module owner for whitelisting Koji packages
* 80f78c7 rename to match what it actually does
* 4c57329 include %module_name, %module_stream and %module_version in the module-build-macros and fix sending active=True in pdc.py
