|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ferdnyc commented 2 years ago Since the stated goal here is to make | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
ferdnyc commented 2 years ago Having the | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
External tools that interact with Koji
need to wait for builds to appear in a repo.
For example, Fedora cli tools 'bodhi' and 'fedpkg'
can create buildroot overrides,
which only become useful
after the override's build appears in the correct repo.
At the moment, 'bodhi' waits for a repo
by invoking the 'koji wait-repo' cli tool
while 'fedpkg' does not wait at all.
In order to make it easier for such tools to wait for a repo,
the wait implementation from 'koji wait-repo'
is moved to koji.utils namespace
where it is available for use through Python import.
(IOW, regarding my previous comment, it would be better to always include the explanatory text in the exception, and change the call here to be something like...)