An improvement would be: disable the auto-start of the MR pipelines [and only enable 'Run pipeline' option on the 'pipeline tab']. But we don't know how to do this..
The current Pause-for-approval (in pre stage) is a away stop this auto-started MR pipeline - and 'continue' only if we need this test to complete. Satish On Thu, 27 Aug 2020, Stefano Zampini wrote: > +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 >
