Pre-review CI

[Bhushan Shah]

On Mon, Jul 30, 2018 at 11:50:48AM +0200, Friedrich W. H. Kossebau wrote:
> More advantages with parallel builds:
> * bigger projects, where building takes some time (krita, kdevelop, plasma-*, 
> etc) and where sometimes patches are reviewed almost in sync, parallel builds 
> mean quicker feedback
> * when doing fix-up for patches which fail on a platform, getting quicker 
> feedback would be also good
> * parallel builds might also mean easier report for results on the different 
> platforms in the jenkins page, so one can quickly see on which platform there 
> are issues (and which experts might be needed)
> * a platform being broken on normal CI for some unrelated reason (outdated 
> deps, platform issues) will also mean the review build breaks there, in that 
> case any later platforms in the single job build would not be reached for 
> review feedback
> * platform-specific issues (like missing includes) which need platform experts 
> will result in a fail before reaching other issues (like regressions in 
> tests), having parallel builds would allow the non-build failing platforms to 
> also run the tests and allow the developer to already investigate the test 
> regression, while waiting for the platform experts to help out with the 
> platform specific issues
> 
> So unless we are short of resources on CI, I really would favour separate 
> builds, to always get feedback for all platforms, instead of doing some try & 
> error walk through all platforms one by one, with the others having to wait 
> for the earlier (and respective people to sort out things there).
> 
> Let's make sure things can be worked in parallel where possible, and as quick 
> as possible, given most FLOSS contributors only have small time snippets to do 
> things.

Your arguments makes sense perfectly.

> Which brings another question: how long would review build logs be kept?
> 
> I could imagine that discarding once a review is closed (discarded or 
> committed) would be fine. But while a review request is open, keeping also 
> build logs for older revisions (at least to a certain count) of a patch under 
> review would be good to have, as sometimes one needs to compare results for 
> different versions.

Builds will stay on CI as long as the review request is open, also we
are thinking of the "cleanup" at regular period to purge the review
request builds which had no updates in "some period".

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180731/1a06d3bb/attachment.sig>