I think we can still consider the middle-ground, where only deprecated multinode jobs, which tripleo infra team is in progress of migrating into standalone jobs, could be made depending on unit and pep8 checks? And some basic jobs will keep being depending on nothing. I expanded that idea in WIP topic [0]. Commit messages explain how the ordering was reworked. PS. I'm sorry I missed the submitted stats for zuul projects posted earlier in this topic, I'll take a look into that. [0] https://review.openstack.org/#/q/topic:ci_pipelines+(status:open+OR+status:m...)
Bogdan Dobrelya <bdobreli at redhat.com> writes:
On 26.02.2019 17:53, James E. Blair wrote:
Bogdan Dobrelya <bdobreli at redhat.com> writes:
I attempted [0] to do that for tripleo-ci, but zuul was (and still does) complaining for some weird graphs building things :/
See also the related topic [1] from the past.
[0] https://review.openstack.org/#/c/568543 [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/127869.html
Thank you for linking to [1]. It's worth re-reading. Especially the part at the end.
-Jim
Yes, the part at the end is the best indeed. I'd amend the time priorities graph though like that:
CPU-time < a developer time < developers time
That means burning some CPU and nodes in a pool for a waste might benefit a developer, but saving some CPU and nodes in a pool would benefit *developers* in many projects as they'd get the jobs results off the waiting check queues faster :)
-- Best regards, Bogdan Dobrelya, Irc #bogdando