Releng would like to have exact commands as part of the Requests. The initial PR is in #271. Some changes were later performed, now part of the releng_requests_prod branch. Let's make a proper changeset from it.
releng_requests_prod
//Edit: The description below is not accurate, ignore it. See further comments below.
I spent some time on this today, and the fun part is, we can't currently do this. The main reason for this feature are these commands:
koji tag-build f{{ release_num }}-compose {% for update in fe_updates %}{{ update.title or update.updateid }}...
and
sudo -u apache bodhi-push --builds {% for update in fe_updates if update.request == 'stable' %}{{ update.title or update.updateid }}...
The koji tag-build one requires a list of builds. But we don't have those. The current PR #271 prints update.title, but that's a mere coincidence that it contains a list of builds (that's the default Bodhi behavior). It's a freeform text field and the update creator can populate it with anything (and some do). We can't even distinguish those, so sometimes the builds would be randomly mixed with words and sentences in the middle.
koji tag-build
update.title
The bodhi-push --builds command is easier. It should be possible to replace it with bodhi-push --updates, and we can provide update IDs just fine.
bodhi-push --builds
bodhi-push --updates
So what to do about koji tag-build? I see two possible options:
a) BBA starts tracking what builds an update contains. That will require a DB schema change. It will also not be completely up-to-date, so it might happen that when an update is edited after our last sync and after we reprint this text into a releng ticket, the command will not contain the latest builds. Admittedly, the same problem happens even now, if releng just copy&paste the list of builds (actually update titles) from the ticket.
b) We'll instead provide a shell script that releng can execute which will query bodhi for necessary updates at real time, list the builds and feed it to koji tag-build. The core command could look like this:
$ curl -sS 'https://bodhi.fedoraproject.org/updates/FEDORA-2023-8b9dbbca5e' | jq -r '.update.builds[] | .nvr' hdmf-common-schema-1.7.0-2.fc38 python-hdmf-3.7.0-1.fc38
So we can generate a for loop with all affected update IDs, run the above command for each of them, and then redirect the final list to koji tag-build. @kevin Is this something you'd be interested at? Note: Epochs are separated in the Bodhi json, so this is currently outputting just NVRs, not NEVRs. Is it sufficient?
Actually, I was wrong, Bodhi now uses update.display_name (code) for an optional different name to display, and update.title always contains a list of NVRs. I even created a test update to verify it. We probably shouldn't completely rely on it, looking at the code, but perhaps it is currently good enough.
update.display_name
Another note, update.updateid is the same as update.alias (code), so we can easily feed that to bodhi-push, which requires aliases.
update.updateid
update.alias
bodhi-push
I'll try to prepare a PR soon.
Yeah, the alias/updateid would work fine for bodhi too (and in fact be a bit less error prone for updates that have a ton of builds)
Sadly, koji needs the actual builds tho.
Thanks for working on this!
There's a PR in #276.
@kevin @adamwill Please see that PR, there are some questions for you. Thanks.
Commit aceaddd6 fixes this issue
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/quality/blockerbugs/issues/275
Please continue any further discussion there.
Log in to comment on this ticket.