packit
copr_build tasks `succeed in 0s` per GitHub UI
As a repo maintainer of container tools using packit service for copr builds on upstream PRs, I'd like to view the total completion time of each copr_build task in the GitHub UI itself, and not have to go to the actual copr build page for it. Currently, the completion time for copr_build tasks is shown as 0s.
Ref: https://github.com/containers/buildah/pull/4681/checks?check_run_id=12197629542 . See any of the other copr_build tasks in there.
Hi, and thanks for the issue!
As for the reported time, what would be the expected value for you? The time for running the RPM build itself? Time from submission in Copr to the end? Or in general the time from the "triggering" (GitHub push/comment/..) to setting the result?
Hi, and thanks for the issue!
As for the reported time, what would be the expected value for you? The time for running the RPM build itself? Time from submission in Copr to the end? Or in general the time from the "triggering" (GitHub push/comment/..) to setting the result?
@lbarcziova hmm, given that everyone would be monitoring that, I think the time from triggering to setting the result would matter to most people.
@edsantiago Thoughts?
I don't have full context here, but I'd be partial to reporting RPM build time: it's the one (I think?) where variation is important. For example, I watch our CI test times constantly, every day, which gives me a sense for what's normal. I can then spot if a recent change has made tests run longer, and look for snags. If these test times included time spent queued up, they'd be meaningless.
I don't have full context here, but I'd be partial to reporting RPM build time: it's the one (I think?) where variation is important. For example, I watch our CI test times constantly, every day, which gives me a sense for what's normal. I can then spot if a recent change has made tests run longer, and look for snags. If these test times included time spent queued up, they'd be meaningless.
@lbarcziova I'll then defer to Ed :D .. Is it possible to make the time reported configurable with total time / rpm time options?
We should have the data available for both, though I'm not sure how I feel about adding complexity in this place :D
Quick clarification to my comments: including provisioning time is fine. I don't know what your terminology means ("submission in copr to the end", "triggering to result"); I just think it's important to report semi-constant times, not times spent waiting for a slot (which could be seconds, minutes, hours).
Quick clarification to my comments: including provisioning time is fine. I don't know what your terminology means ("submission in copr to the end", "triggering to result"); I just think it's important to report semi-constant times, not times spent waiting for a slot (which could be seconds, minutes, hours).
Ed, there are multiple times listed on a copr build job, not yet seen on the github UI. See: https://copr.fedorainfracloud.org/coprs/rhcontainerbot/packit-builds/build/5911547/ for example.
We should have the data available for both, though I'm not sure how I feel about adding complexity in this place :D
@mfocko sure thing, build time would be fine then :D
thanks @lsm5 @edsantiago for clarification!
I just think it's important to report semi-constant times, not times spent waiting for a slot (which could be seconds, minutes, hours).
agreed, going with the build time only would be probably more suitable