Additional note: One way to completely avoid MR pipelines is to not create an MR for a work-in-progress branch
Satish On Thu, 27 Aug 2020, 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 >
