It used to be possible to do
koji wait-repo f42-build
to wait until the next newRepo task for that tag finished.
Now that does nothing, exits immediately, and just gives me the previous repo, which is not what I want.
Even doing
koji wait-repo f42-build --request
does the same thing (exit immediately, giving presious repo as result), and does not schedule a newRepo, from what I can tell (only adding at least one --build parameter actually seems to cause a newRepo to happen).
--build
This is a problem - I don't always have an explicit to wait for (for example, waiting for a newRepo after a package was blocked from a tag). That workflow seems to be impossible with the koji CLI after 1.35, since there's no way to specify waiting until a build no longer is in the repo, and just doing wait-repo no longer waits until the next newRepo finishes, but returns immediately (both with and without --request).
wait-repo
--request
At the very least, I think koji wait-repo <tag> --request without specifying a build not doing anything is a bug.
koji wait-repo <tag> --request
(Side note: it was also very nice that the command gave very user friendly output like "waited 10:33 for build to be in tag ", now that message is gone, and is replaced by jargon that's not really helpful:
$ koji wait-repo f42-build --build fastfetch-2.27.1-1.fc42 The --request option is recommended for faster results This tag is not configured for automatic regeneration Got repo 6524273 Repo info: https://koji.fedoraproject.org/koji/repoinfo?repoID=6524273
See also comments in #4227
The current wait-repo is waiting for a valid repo, but not necessarily a current one. In many cases there is already a valid repo, hence no wait. Repo generation has changed a lot in 1.35, but #4228 provides a much closer analog of the previous behavior.
Metadata Update from @mikem: - Custom field Size adjusted to None
Metadata Update from @tkopecek: - Issue set to the milestone: 1.35.2 - Issue tagged with: testing-ready
Metadata Update from @mfilip: - Issue tagged with: testing-done
Commit 9b08aad4 fixes this issue
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/koji/issues/4226
Please continue any further discussion there.