I noticed that when Koji was busy with the mass rebuild and CI scratch builds took a while to finish, they all stayed in the Pedning state despite actually succeeding in ~20 hours.
Unfortunately, I don't have an example because the CI where I saw this was already restarted.
An example such build was https://koji.fedoraproject.org/koji/taskinfo?taskID=120785975 for https://src.fedoraproject.org/rpms/python-sentry-sdk/pull-request/10
Another example is https://src.fedoraproject.org/rpms/python-appdirs/pull-request/10
Same in https://src.fedoraproject.org/rpms/python3.13/pull-request/108 + 109.
The scratch build took longer than 4 hours and it never reported back.
I assume that this is due to the 240 minute timeout in https://github.com/fedora-ci/dist-git-build-pipeline/blob/6ecc543b3c6d723fcc2f0eff47a918392506021e/Jenkinsfile#L91.
For the llvm repo, scratch builds always take longer than this, so they always end up in pending state and dist-git tests are never executed.
Would you submit an MR for raising the timeout pls??
Done: https://github.com/fedora-ci/dist-git-build-pipeline/pull/41
But I'm not familiar with whether significantly increasing this timeout would cause other issues.
Considering the build keeps running, what is the purpose of the timeout anyway? (E.g. should the build be canceled when the job times out?)
I assume the purpose is to avoid leaving processes hanging around forever if something goes wrong...
I'd appreciate it if someone working on CI could look at the PR and check whether it's possible to raise the timeout. Having working dist-git and installability tests would have saved us a lot of time last week, and we can't get them without a longer timeout on the scratch build.
Another example https://src.fedoraproject.org/rpms/rust/pull-request/42#