In order to generate Pungi composes including scratch module builds to actually test the scratch modules, we need to have the final per-architecture modulemd files (See modulemd.$arch.txt in Archives section of real Koji module build here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1373976).
Downstream ticket: https://pagure.io/odcs/issue/289.
Without this, it is not possible to include this module in a compose done by Pungi. There are multiple options to fix this:
1) Create CG module build even for scratch module builds
This has been considered in the past, but the decision was that we should not create CG build for scratch builds so they are not shipped by a mistake. It is also the same behaviour as for RPM builds. I therefore think this is not right solution, but in case you think it might be possible solution, I'm also not against it :).
2) Add new API endpoint to compute the final modulemd file for scratch module build
This would be quite simple API. It would take the scratch module build ID and run this for cycle https://pagure.io/fm-orchestrator/blob/master/f/module_build_service/builder/KojiContentGenerator.py#_758, but instead of storing the results to file, it would return it.
Pungi/ODCS could then be extended to get the modulemd files from MBS API directly. I can write this API endpoint myself if you decide it's good solution.
3) Store the per-architecture modulemd files in the MBS database
We could also store the final modulemd files in MBS database directly for every module build, including the scratch-module build. I personally think this is not good option, because in 99% of cases, these files wouldn't be needed, but it is an option.
4) Store those files "somewhere" in Koji
I'm not Koji expert, but maybe there is a way how to upload these files to Koji and make them accessible to Pungi/ODCS even without creation of Koji build. These files don't have to live there for long time, because scratch-builds are useful only for certain time after their build.
From Pungi point-of-view as a consumer, I would say either 2 or 3 would be preferable. I can imagine a query to MBS that would return the final modulemds (either all arches at once or one in each request).
Storing it in Koji seems like a bad idea. Creating builds could be dangerous, since they would have to be somehow special so as to not allow any tagging. I don't think Koji wants to support that. Storing files outside of builds or tasks also seems very fragile.
PR #1637 implements solution number 2
The danger of solution no. 2 is that because we are recalculating, a future code change could change the result. But perhaps that does not matter for this use case?
Right, I'd say for this use case it shouldn't matter, since this will be used for testing scratch builds - these files should only be needed for the very short term.
Commit 31fd668 fixes this issue
to comment on this ticket.