[gmx-developers] merge request pipelines

[Eric Irrgang]

Thanks! It looks like the new setting works as expected. Artem was able to approve and merge a fast-forward-ready change, then immediately approve, rebase, and queue a successful merge that went in 20 minutes later when the pipeline finished.

As before, though, there are still jobs that should prevent merges but do not (because they are not included in the (one) pipeline that matters). This is the background of the remaining issue.

I can volunteer to provide the adjusted gitlab-ci config if a couple of people can volunteer to review the change implementing an agreed-upon policy.

See you at https://gitlab.com/gromacs/gromacs/-/issues/3617 :-)

Best,
Eric

> On Jul 30, 2020, at 5:16 PM, Paul bauer <paul.bauer.q at gmail.com> wrote:
> 
> Hello as well from my side!
> 
> I can change the "Merge Trains and pipelines for merged results" option right now, and agree that this doesn't work the way I expected it to be in the beginning.
> 
> For the other issues I would prefer to have some more in depth discussion on Gitlab first, but I need to think about the merits of the proposals.
> 
> Cheers
> 
> Paul
> 
> On 30/07/2020 14:14, Eric Irrgang wrote:
>> Hi Devs.
>> 
>> I just submitted https://gitlab.com/gromacs/gromacs/-/issues/3617 with 2 proposals to reduce the number CI pipelines we run while increasing their utility.
>> 
>> I think we can and should disable the "Merge Trains and pipelines for merged results" option.
>> 
>> It does not seem appropriate for our workflow. We already require an identical pipeline to succeed before the merge train can even be launched, and the only case where the "train" part works for us will be equivalent to just using the "merge when pipeline succeeds" button that we will have when we turn off the merge train option.
>> 
>> Also, I think we should make sure that the pipelines that block merge requests actually include all of the tests that we think should be blocking. This requires a little more work than just toggling an option. At the same time, we can and should stop running two pipelines for every push to the repository. Please see the issue description for more information and links to relevant GitLab documentation.
>> 
>> https://gitlab.com/gromacs/gromacs/-/issues/3617
>> 
>> On a related note, it should now be possible (for some developers manually) to trigger pipelines for forks on our GitLab Runner infrastructure. https://gitlab.com/help/ci/merge_request_pipelines/index.md#create-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project
>> 
>> Best,
>> Eric
> 
> 
> -- 
> Paul Bauer, PhD
> GROMACS Development Manager
> KTH Stockholm, SciLifeLab
> 0046737308594
> 
> -- 
> Gromacs Developers mailing list
> 
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or send a mail to gmx-developers-request at gromacs.org.