Hi,
On Tue, Sep 4, 2018 at 4:00 PM Owen Taylor <otaylor@redhat.com> wrote:
I haven't dealt with modularity yet, really, so tell me if i wrong (i'm
kind of guessing a little bit from briefly snooping around). module
building is like so, right?
1) user runs `fedpkg module-build` in a the module git repo
2) this gets submitted to a service to build the module
3) the service reads a metadata file with a list of rpms to build
4) the service submits those builds to koji
5) sometime later owner-sync-koji runs and does a massive
loop over all modules and finds all packages associated
with each module and tags them all with f29-modular-updates
Not quite. First, owner-sync-koji is about adding packages/containers/modules to a tag - basically allowing a build of the object to be tagged into that tag. Not actually tagging builds. Second, what would eventually be tagged here is a complete module build or a Flatpak container build, not package builds.
so assuming i have the gist of things captured above, my question
is…why doesn't the service that submits the builds, also do the
tagging ? it just seems strange to have the huge loop doing extra
work. if the service did the tagging, then it could also do the flatpak
detecting, and do the additional tagging. judging from the koji
command line, it seems koji even allows tagging multiple builds at
the same time, so i guess the build service could do them all in
one swoop
MBS (that service) does do the actual tagging of the module build. Component builds don't get tagged into f29-modular-updates.
Anyway, take my suggestions with a grain of salt because i have
an incomplete understanding of the architecture, MBS, koji, etc.
A complete understanding is much rarer :-) I wouldn't claim to have that either.
Things are especially confusing because support for non-package builds in Koji is visibly after-the-fact.
Owen