+1 for the new infrastructure
> On Aug 27, 2020, at 6:59 PM, Satish Balay via petsc-dev
> <petsc-dev@mcs.anl.gov> wrote:
>
> BTW: here are some reasons for using the MR pipeline instead of the web
> interface pipeline.
>
> - it tests branch+master (more useful?) - instead of branch [web pipeline].
> - you can skip the forced re-bases that were required when CI changed [i.e
> even if your branch is off old master - the latest CI settings from latest
> master will get used by MR pipeline]
> - it enables testing of MRs from forks. [so the additional complexity of that
> workflow is now gone. Note: only developers can start these pipelines - from
> the pipeline tab on the MR web page]
>
> And as mentioned - developers can ignore this, and continue to start
> pipelines from the web interface.
>
> There is now some additional complexity in figuring out if the latest changes
> are tested [and by which pipeline, MR or web etc..] - but this part of the
> workflow should primarily affect integrator group.
>
> Satish
>
> On Thu, 27 Aug 2020, Satish Balay via petsc-dev wrote:
>
>> On Thu, 27 Aug 2020, Jacob Faibussowitsch wrote:
>>
>>> Why does one pipeline request spawn two separate pipelines now?
>>> Specifically one is a normal pipeline whereas the other includes some sort
>>> of manual approval button which “runs” indefinitely if you don’t either
>>> cancel it or approve it.
>>
>> The 2 pipelines you see are
>> - readdocs pipeline
>> - merge-pipeline - auto starts - does the pre stage and pauses.
>>
>>> I think this was somewhat discussed in a previous MR
>>> (https://gitlab.com/petsc/petsc/-/merge_requests/3063
>>> <https://gitlab.com/petsc/petsc/-/merge_requests/3063>) which indicates it
>>> is useful for doing a pipeline of the branch+destination but how is this
>>> different from the existing merge-train infrastructure that was already in
>>> place?
>>
>> Its not a replacement for merge train.[merge train is a way to do the merge
>> when the MR is tested and ready for merge]
>>
>> However you can use this as a replacement for starting a new pipeline from
>> the web interface https://gitlab.com/petsc/petsc/-/pipelines/new
>> [i.e instead of starting a web interface pipeline - you just go to the MR
>> page - 'pipeline tab' and hit continue]
>>
>> Or you can ignore this and continue to use the web interface.
>>
>>
>>> It is annoying to have to manually go in and cancel the phony pipeline
>>> every time (not to mention twice as many emails from gitlab notifying me
>>> the femtosecond these pipelines fail).
>>
>> You shouldn't have to cancel the automatic MR pipeline. They should just
>> stay paused.
>>
>> And I don't remember getting e-mails from these stalled MR pipelines.
>> Perhaps you got them because of pre-stage failures?
>>
>> However if you have errors in pre stage tests - you might as well check and
>> fix them.
>>
>> The one thats causing most trouble is readdocs pipeline. Its probably best
>> to disable it until its issues are resolved.
>>
>> Satish
