How should look specs for regular rpm build?
{ "meta": { "schema": "schema_reference", "version": "xyz" }, "buildenv": { "name": "buildroot-<tag>-<repo_id>", # this is the name provided by koji "type": "mock", "arch": "x86_64", "opts": {} }, "repositories": ["brew repo url for repo_id"], "build_tag": { "arches": "x86_64,i686", "extra": {"mock.new_chroot": false}, "id": 3, "locked": false, "maven_include_all": false, "maven_support": false, "name": "fedora-35" } }
Issues with generating mock config in kbi without calling the hub - repo_id is incompatible with genMockConfig which would mean extending it to be able to work with repo urls (or reviving opts['url']).
genMockConfig
opts['url']
Or whole mock.cfg could be part of buildenv['opts'], but that would force some undesired values (e.g. basedir). Maybe some options can be dropped and left on kbi config? build_tag wouldn't be much needed in such case (but still can make sense for other kbis, should be just getTag(extra=True) or more getBuildConfig?).
getTag(extra=True)
getBuildConfig
How logs would be monitored in this case? We need to know where are the logs located before spawning kbi or force kbi to log somewhere. For mock it is in defined location which can't be moved, so maybe additional command? e.g. kbi-tool logs --path which could be called after init? That directory could be monitored after spawning `kbi-tool build``.
kbi-tool logs --path
{ "meta": { "schema": "", "version": "" }, "build": "rpm", # rpm/srpm/scm "sources": [ "srpm url", # https/file url for rpm/srpm ("srpm" build means srpm rebuild) "scm_url#hash", ["rhpkg", "source"] # for scm ], "parameters": [] }
How to work with srpm from scm? For policies it would mean that we need to do one checkout in koji to apply scm policy, etc. Plugins preparing the content will not work at all. Maybe instead of delegating this to kbi koji would do everything and provide resulting directory on the same machine. But in such case it is not reproducible on dev's machine with just kbi and koji api.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/koji-planning/issues/2
Please continue any further discussion there.