[Development] Allow to do parallel integration (was: Proposal: New branch model)
Allan Jensen
Allan.Jensen at qt.io
Wed Jan 30 13:55:41 CET 2019
On Wednesday, 30 January 2019 13:38:46 CET Jedrzej Nowacki wrote:
> On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
>
> > On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> >
> > > Jedrzej Nowacki (30 January 2019 11:08)
> > >
> > >
> > > > MÃ¥rten pointed out that we can check for conflicts up front. Not only
> > > > against HEAD of the target branch, but also against all build
> > > > branches.
> > > > That is even nicer as there is no need to start a job that would
> > > > likely
> > > > to be rejected at the end.
> > >
> > >
> > > That'll only find VC-level conflicts.
> > > It's no help in finding the kinds of breakage that only testing
> > > reveals.
> > > It'll also sometimes lead to rejecting a change needlessly, because the
> > > already-integrating branch it conflicts with is about to fail its
> > > testing.
> > > Still, I guess restaging a little later can fix that ...
> >
> >
> > We could do speculative merging. Guess if the previous commit will merge
> > on
not, and stage the following commit based on that guess. Or stage two
> > versions of the next commit, one for success of the previous and one for
> > failure. That latter would use 3x the VMs for 2x the throughput.
> >
> > 'Allan
>
>
> We could. In such case we do not allow regressions, but we waste ~50% of
> speculative builds. I believe that would be much better accepting the risks,
>
the throughput maybe N times higher, when N is count of parallel build
> branches. In the end reverts are just one click. Btw. after revert coin
> will likely detect that the revision was build and it would just use cached
> results, so it may even avoid running tests.
>
At the current pass rates it would be a better speculation to assume that the
other commits do not merge.
'Allan
More information about the Development
mailing list