[gmx-developers] merge request pipelines

[Paul bauer]

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