Brew publishes the NVR on tag change messages, but Koji upstream does
not. This constructs the NVR based on the name, version, and release
in the messages.
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.
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.
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.
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.
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
