<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<font size="+1">Does branch+master mean an automatic rebase?<br>
<br>
Scott<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 8/27/20 10:59 AM, Satish Balay via
petsc-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LFD.2.23.451.2008271150360.69132@sb">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, 27 Aug 2020, Jacob Faibussowitsch wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
The 2 pipelines you see are
- readdocs pipeline
- merge-pipeline - auto starts - does the pre stage and pauses.
</pre>
<blockquote type="cite">
<pre wrap="">I think this was somewhat discussed in a previous MR (<a class="moz-txt-link-freetext" href="https://gitlab.com/petsc/petsc/-/merge_requests/3063">https://gitlab.com/petsc/petsc/-/merge_requests/3063</a> <a class="moz-txt-link-rfc2396E" href="https://gitlab.com/petsc/petsc/-/merge_requests/3063"><https://gitlab.com/petsc/petsc/-/merge_requests/3063></a>) 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?
</pre>
</blockquote>
<pre wrap="">
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 <a class="moz-txt-link-freetext" href="https://gitlab.com/petsc/petsc/-/pipelines/new">https://gitlab.com/petsc/petsc/-/pipelines/new</a>
[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.
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Tech-X Corporation <a class="moz-txt-link-abbreviated" href="mailto:kruger@txcorp.com">kruger@txcorp.com</a>
5621 Arapahoe Ave, Suite A Phone: (720) 974-1841
Boulder, CO 80303 Fax: (303) 448-7756</pre>
</body>
</html>