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
--
Tech-X Corporation kru...@txcorp.com
5621 Arapahoe Ave, Suite A Phone: (720) 974-1841
Boulder, CO 80303 Fax: (303) 448-7756
