Needs action="store_true", otherwise I got "koji: error: --buildroots option requires 1 argument". Anyway, my idea was that without this option it would print (always) the number of buildroots, but with this option it should print buildroot IDs, even if there are thousands of them.

If there could be multiple repos, we should get the data via multicall.

This could be outside of the loop.

Turn boolean to yes/no (e.g. as in taginfo)

Use repoID=repo_id, now you're in fact calling listBuildroots(hostID=repo_id)

if is not needed here (len([]))

Neither the new cli repoinfo handler nor the updates to the web handler provide a way to list these buildroots, which is as key part of the request in #2549

The repo_references function isn't quite doing what we want here (it only reports active repos). I don't think we should use it here. Instead, we should probably do this in a single query adds a join and condition for the repo id.

@mikem yes, I add list of buildroots ID with --buildroot option in CLI...and when we want to have it in webUI, we can add it as new link on number of buildroots in repoinfo webUI. Tomas checked that there could be ~2500 list of buildroots. Therefore we don't want to print list of buildroots as defaults.

@tkopecek fixed
@mikem I added to repoinfo webUI link to buildroots and created new webUI page with buildroots info

Neither user nor tag are supplied via buildroots function.

REPO_STATES != BR_STATES

In case of buildroots page makes sense to add also buildrootinfo page, so you can click on buildroot ID and get all the buildroot info.

We also need backward compatiblity for repoinfo command (to be able query older hubs).

That's not true - it prints list of IDs.

Let's print the firstID on next line.

Could be colorized in same way as build/task states (maybe even the icons).

Commit 3f3c56fd fixes this pull-request