Re: How to do add-on merge requests and get a pipeline to run?

Werner LEMBERG <[email protected]> writes:

>>> I think that you have to physically add the commits from MR 3111
>>> before the commits of MR 3115 to make the pipeline get executed (and
>>> tell the users in the MR description to ignore these commits).  It
>>> seems that gitlab's CI doesn't support the case where you want to
>>> merge branch A into an arbitrary branch B.  Branch B must always be
>>> 'master' AFAICS.
>>>
>>> Maybe Jonas knows more.
>> 
>> From what I have read so far, I consider it likely that once request
>> 3111 gets merged upstream, request 3115 will be reoriented on master
>> and will then presumably run the pipelines just fine.
>
> Probably yes.
>
>> But right now it doesn't.  Which means slow progress of projects
>> done in multiple steps if the first step has to go through all
>> stages of acceptance before the second one can even get review
>> attention.
>
> As a told you: Let's assume MR #1 contains commits a, b, c, and MR #2
> commits d, e, f, and MR #2 depends on MR #1.  To make the pipeline run
> successfully for MR #2, copy commits a, b, c so that MR#2 actually
> consists of a, b, c, d, e, f.  This is tedious and awkward to manage,
> I know, but better than waiting IMHO.

Uh, there is a hard dependency.  Of course the merge request branch
contains all relevant commits.  The diff is against its dependent branch
which makes reviewing for humans easy, the snapshot contains every
necessary change, and it is rebased so that exactly the same commits as
the parent merge request branch are in the ancestry and of course in
every work tree checkout.

I think we are talking past one another.  You can perfectly well check
out merge request branch 3115 and compile it, and it will contain every
single change in branch 3111 and every commit as well.

-- 
David Kastrup