The following chromium job has been running for the past 2 days and it
looks like it is backing up the rest of the build queues. There are now
168 build jobs waiting in the queue.
Running Project Build Package Name Package Version Chroot
2 days lantw44/chromium 362159 chromium
I just upgraded Copr instance to new version.
There is one big change. You can now lower priority of your build.
It was introduced to easy rebuild of rubygems and pypi. But it can be
used by CI systems later.
Copr-cli from our git, has --background option already. It lowers the
priority. But due compatibility reason we will not push the package into
main Fedora and we will wait one or two weeks.
If you want to give it try, then you can install it from our copr project.
I am just sending more than 70 000 tasks to production instance of Copr. Why? Because of:
I'm throttling the speed and I am sending one task each 15 seconds. So it will take 12 days before I sent everything.
On the other hand there should be no long queue. If you will see some long queue in "Waiting" despite my throttling,
then I would like to emphasise that every user (including me) can have only 6 concurent tasks. And we can have up to 25
builders in parallel. So there is still 19 builders always available to process task of other users, so your task should
be build as fast as usually.
Of course there can be some bug. So if you think that something bad happened then please contact me.
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
I'm wondering if the 24 hr timeout change is too long. I tossed a bunch of builds in, and it decided to stall out with no log messages on four of them, filling the build machines up so others builds are stuck waiting now. These were three 10 minute builds and one two hour build on a normal decent quad core VM. Perhaps 24 hrs is too long to timeout? Or limit the number of build machines one user can utilize at a time?
Just a thought. Thanks!