Closed nikromen closed 5 months ago
Showing the actual build in packit dashboard can be done this way:
deciding whether the build is koji or copr based only on packit_id is harder. However what I do on backend is trying to get copr build for packit_id
from packit API. If I don't get 2XX response, then I assume it's koji build (note that the IDs may overlap but since the difference between packit_id for koji and copr is enormous, the small IDs for koji builds no longer exists for copr builds so I assume it's safe).
@lachmanfrantisek do you know whether a more convenient way to differentiate koji and copr builds based only on packit_id exists?
@lachmanfrantisek do you know whether a more convenient way to differentiate koji and copr builds based only on packit_id exists?
What is actually the full use case/process here? What do you have and what do you need?..;)
A few notes:
packit_id
is not shared between Copr and Koji builds. It might work just because we have many more Copr builds. The Packit API can be enhanced -- maybe we can add a new endpoint so you don't need to hack something outside of Packit.
Thanks for your response, Franto. I'll summarize out conversation from Monday's mtg so we have an update here:
Thanks Jirko for summarising this! Maybe one missing note that starting with Copr builds, for now, should be really fine. There are not many users of upstream Koji scratch builds. With downstream Koji builds, we are just working on saving them into the database.
Just spotted this today and found this issue when wanting to create a new one..;)
The link as is is currently a bit misleading so I would either remove it or blindly use https://dashboard.packit.dev/results/copr-builds/{packit_id}
. (Don't you already know what type of build this is when you're showing the logs to the user?)
the link in instructions redirects to copr builds every time even when this packit build should redirect to koji builds