Le 30/10/2014 15:14, Andrew Mason a écrit : > Greetings all, > I'm looking to gain some understanding of the CI infrastructure and > thought it might help if I worked on a few junior bugs as a goal. I was > wondering if there were any particular issues that people could suggest > as a good starting point. Zuul looked like an interesting project as I > am fan of Git; If anyone has any particular gripes then I'm happy to > head in the direction if you're willing to offer some assistance when > you have the time. > > Kind regards > Andrew
Hello Andrew, I have a few ideas which I never bothered filling as bugs so here they are: Zuul client) The Zuul client let and administrator interacts with the scheduler, currently let you enqueue a new change, promote a change in the pipeline queue and show the currently running jobs. Current usage: http://ci.openstack.org/zuul/client.html We could use a method to for retriggering a single change. If we use enqueue, the scheduler would not reenqueue it because it is already present. Something like zuul requeue :D I would love the 'show' command to provide: - a thin wrapper around Gearman "status" and "workers" administrative commands. Possibly with filtering and an option to select the output format (PrettyTable/json) - the ability to dump the various queues (event, management..) and per optionally per pipeline for the event one https://review.openstack.org/#/c/68828/ implemented the show running-jobs command. Could be a good base. An utility that would send a manually crafted event, pass it through a layout and yield the workflow decision that has been taken. That would be quite useful to write integration tests of a layout workflow (for example ensure 'recheck' on a patch that has Approval +1 is enqueued in the gate pipeline). Zuul webapp) Add an administration interface that would let folks promote/enqueue changes directly from http://status.openstack.org/zuul/ . That would let scale out administrations tasks since a shell access would no more be required. A change that just has been submitted list jobs as being "queued". Could use a next state of "merge pending" while waiting for the merger to complete its work. Zuul logs) The debug logs can take a lot of disk space unfortunately logging.handlers does not have one to compress rotate files which would be handy. The pipelines loggers use their class name as a key ie: zuul.IndependentPipelineManager: zuul.DependentPipelineManager: Would be nice to replace the key with the pipeline name, possibly something like: zuul.pipeline.gate zuul.pipeline.postmerge ... When a change is received, it is passed through all the pipelines that decides whether they are interested. When dismissing the event, each pipeline log at error level causing output like: ERROR zuul.IndependentPipelineManager: Unable to find change queue for project foo ERROR zuul.IndependentPipelineManager: Unable to find change queue for project foo ERROR zuul.IndependentPipelineManager: Unable to find change queue for project foo Maybe such error should just be an info and an error thrown if none of the pipeline used the event. -- Antoine "hashar" Musso _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
