[petsc-dev] Pause-for-approval Pipelines?

[Satish Balay]

The CI process does a merge of the branch with master - and uses this commit for the test pipeline. i.e the branch is not modified.

Obviously if the merge fails - the test pipeline won''t get run.. [when there are merge conflicts - the MR page indicates this anyway]

Satish

On Thu, 27 Aug 2020, Scott Kruger wrote:

> 
> 
> Does branch+master mean an automatic rebase?
> 
> Scott
> 
> 
> On 8/27/20 10:59 AM, Satish Balay via petsc-dev 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
> 
>