Hi Tobias,

Sorry for my lake of information about your CI (Gerrit or not, etc.) and your workflows. 

What about running these jobs on different pipelines ? 

At leboncoin, we have 3 ‘check’ pipelines (means running on each patchset): quality, integration and build. 

With this setup, we can have an asynchronous vote on Gerrit under different labels: fast voting on quality pipeline/label (ex: code linter - small jobs) and a slow result with build pipeline/label (long run jobs). 

BTW, if I’m missing the point, your idea looks good to me. 

Kind Regards. 
Guillaume

Le 13 nov. 2018 à 21:48, <Tobias.Henkel@bmw.de> <Tobias.Henkel@bmw.de> a écrit :

Hi Zuulers,

 

We have several projects that have buildsets with fast (few minutes, e.g. linters) and longer running (> 40 minutes, e.g. big fat c++ compilation) jobs.

We often see the case that one of the linter jobs failed and already could give feedback. However zuul waits for the completion of the fat compile job before reporting.

Generally this is the desired behaviour because we want to give as much feedback as possible.

However some projects may want to decide that quick feedback is more important than the most complete feedback possible.

 

So I would propose to add a ‘report-on-first-failure’ flag to the project-pipeline. The default would be false in order to retain the current behaviour.

If the deque happens the aborted jobs will have the ABORTED state so it can be clearly seen in the reporting that these were aborted.

 

Enabling this for certain projects also could help to reduce resource consumption in quota-constrained periods.

 

What do you think about this?

 

Kind regards

Tobias

_______________________________________________
Zuul-discuss mailing list
Zuul-discuss@lists.zuul-ci.org
http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss