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

Barry Smith bsmith at petsc.dev
Thu Aug 27 16:44:23 CDT 2020



> On Aug 27, 2020, at 11:45 AM, Satish Balay via petsc-dev <petsc-dev at mcs.anl.gov> 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.

  Satish,

    How are these related? When you make a MR or push on a MR are TWO distinct pipelines really started?

> - readdocs pipeline
> - merge-pipeline - auto starts - does the pre stage and pauses.

how are they related? 

I understood Jed wanted the readdocs pipeline done automatically so it was easy to review any readthedocs changes since the properly formatted new docs with the changes was made automatically in the MR and pushes. I am fine with this, though it seems silly to always do it instead of not just doing it when there is a change to docs or maybe a docs label. Just curious, is this done with a merge to master ?

The second pipeline I don't understand. Aside from letting people who don't use the GitLab API to  not have to hunt for the Pipelines window and cut and past their branch name in and the merge to master business does it serve any other purpose? Could we unset this for certain people who don't like it in the .gitlab-ci.yaml file?

  Barry


> 
>> 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



More information about the petsc-dev mailing list