On Thu, 27 Aug 2020, Barry Smith wrote: > > > > On Aug 27, 2020, at 4:55 PM, Jed Brown <j...@jedbrown.org> wrote: > > > > Barry Smith <bsm...@petsc.dev> writes: > > > >>> - readdocs pipeline > >>> - merge-pipeline - auto starts - does the pre stage and pauses. > >> > >> how are they related? > > > > Not at all. The ReadTheDocs pipeline is managed by readthedocs.org. > > > >> 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 ? > > > > We don't have control at that granularity. We can disable the feature, but > > then we don't have a good way to review changes there. I want to make > > writing and reviewing documentation changes as low friction as possible > > (because our docs, especially the manual, are pretty low quality and often > > out of date). > > > > I figure if ReadTheDocs feels like they're wasting too much compute, they > > can add a finer grained control. > > As I said I am fine with this readthedocs, assume it works. > > > >> 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? > > > > If the second pipeline has nothing to do with readthedocs then why did your > MR also include it? Was it two completely different unrelated things in one > MR? Or does readthedocs require MR pipelines to be on and somehow this > requires a regular MR pipeline be run even though not directly connected to > readthedocs, your stopping it and waiting is the only way to prevent it from > running fully? What about for some people supporting stopping it and > cancelling it once readthedocs is done or even deleting it then so it doesn't > clog the pipeline window with irrelevant stuff? > > I understand the utility of this second pipeline and the button for many > people but it does clog up the pipelines. I think some people should be able > to turn it off. > > > > > What's wrong with using the API to release the paused job instead of using > > it to start a fresh pipeline? > > Generally I like to pass the Pipeline before making a PR. So the test on > creating a new MR is annoying. Yes after the initial MR I might be able to > release the paused job in lieu of starting pipelines fresh. It would be nice > to send some pushes that don't trigger a pipeline start at all because I know > I don't need one. Maybe that is possible, I'll need to investigate.
The above is hard for me to digest - so I think its best to frame this differently. 1. ReadTheDocs is not setup in .gitlab-ci.yml 2. We have merge_request pipelines - and web pipelines [api pipeline is similar to web] 3. I think both - web, merge_request pipelines trigger ReadTheDocs job 4. Web pipeline appears to get a 6th stage from the ReadTheDocs job [because both are run on the branch - and the hash matches] 5. Web pipelines are manually started. But MR pipelines are automatically started [I don't see an option to disable this auto start] 6. The ReadTheDocs job is run on the branch - even when triggered by merge_request pipeline. As the branch hash and the merge hash are different - they are getting listed as 2 pipelines. And I think this separate pipeline listing by ReadTheDocs is causing grief with the MR webpage [it assumes the tests have passed] So the likely fixes: - ReadTheDocs triggered by MR pipeline should use the merge - and not the original branch [and not create a separate pipeline listing]. This should cut down the pipeline listing by half - somehow disable auto start of MR pipelines [this should eliminate the remaining pipeline listings. Satish
