Handling merge requests from forks

[Jellby]

A very significant flaw of the merge request model in GitLab is that it seems the only CI linked to the merge request is in the source project. This may be alright in very simple projects and configurations, but I don't think the CI from an external project should be trusted:

1. It could have no access to specific runners
2. Secret variables will not be available
3. Runner time limits could be different

These could cause CI jobs in a fork to fail, with almost no chance of fixing them. Perhaps more serious, I imagine it could be possible for a malicious user to set up a customized runner that will report success where a test should fail, in which case the CI would appear as passing, but it will be broken when run in the target project's runners.

I don't know if there's any way to run pipelines for merge requests on the target project. Apparently the SHA for the MR commit is created in the target project, and a pipeline can be run if a tag or branch is added to it, but it is not connected to the MR. See for example:

https://gitlab.com/Jellby/test/merge_requests/10 The CI on the source project fails (artificially forced to do so, but it could happen in a real case for legitimate reasons as seen above).

The commit appeared in the target repository: https://gitlab.com/Jellby/test/commit/1ca482baa35df4287afaf5313a2f64fc59b62ed5

I created a tag: https://gitlab.com/Jellby/test/commits/testingMR!10 and ran a pipeline: https://gitlab.com/Jellby/test/pipelines/22898164 on the target project, but the MR does not show its result, so the MR can't be accepted.

If someone can find a good solution, that would be great. Otherwise, I'd suggest at least an option to ignore MRs not originating from the same project (and it should be the default if the guarantee for a green master is important).

[nanonyme]

This sounds more like an issue with Gitlab than Marge to me. There should be a way for project members to permit running code from a fork on original project CI.

[Jellby]

Everything Marge does (or at least everything I want her to do) is an issue with GitLab, it should all be handled natively by GitLab. But I thought the point was to implement what GitLab was missing.

[nanonyme]

Sure. We did bump into this I think three times over past 24 hours with new contributors.

[RalfJung]

This is a roadblock for us. I originally thought marge-bot works like bors, where the bot pushes the to-be-pushed-to-master commit (MR merged into master) to a staging branch, tests that, and then fast-forwards master if CI succeeds. That would help with the fork situation as well since this new branch is located in the main repository, not the fork. But it looks like marge-bot actually relies on CI in the original MR branch, and that won't cut it for us as we need specific runners that forks do not have access to...

[Jellby]

@RalfJung You may want to try the MargePT2 branch in my fork, which among other things is intended for that (given that the PR is now sitting in limbo). Alternatively, I believe in GitLab, a developer with permission to run pipelines on the parent project can manually (through the web interface) start a pipeline for the MR, which is run on the parent project, not the fork.

[RalfJung]

@Jellby is that the branch behind this PR: #113 ? I'm a bot worried about using a fork; not knowing the original code it is hard for me to evaluate the risk that would entail.

Alternatively, I believe in GitLab, a developer with permission to run pipelines on the parent project can manually (through the web interface) start a pipeline for the MR, which is run on the parent project, not the fork.

That is interesting, I'll do some digging, thanks! If GitLab indeed supports this, couldn't mage-bot "push that button", so to speak?

[RalfJung]

Ah, looks like that is a premium feature... bummer.

[Jellby]

It should be ahead, rather than behind. The branch is my working code, which we are using in https://gitlab.com/Molcas/OpenMolcas, and has been updated after #113 was created (and it contains other changes like #114). However, I'm not 100% that my latest changes have been pushed to the branch, and I can of course not give any assurance on the quality of the code or its behavior for any use case different from mine...

If I remember correctly, in my current branch marge is actually "pushing that button". (I'm using gitlab.com, so premium is not an issue... but impersonating is.)

[RalfJung]

However, I'm not 100% that my latest changes have been pushed to the branch, and I can of course not give any assurance on the quality of the code or its behavior for any use case different from mine...

Of course. Your help is already much appreciated. :-)

If I remember correctly, in my current branch marge is actually "pushing that button". (I'm using gitlab.com, so premium is not an issue... but impersonating is.)

That wouldn't work on our instance then I think... (as a publicly funded research institute, we cannot afford premium, but since we are primarily doing research not teaching, GitLab won't grant an educational license :/ )

[RalfJung]

If I remember correctly, in my current branch marge is actually "pushing that button". (I'm using gitlab.com, so premium is not an issue... but impersonating is.)

I think using a staging branch would actually be the better option since it also solves #296.

[snim2]

@RalfJung if some of your repos are public and open source you might be able to apply for this BTW.

[RalfJung]

Some of our repos are public and open-source but by far not all of them, so if I understand this correctly we are not eligible to the open-source program.

The code we want to use marge-bot for is open-source though... we'd probably have to have two gitlab instances, one for the open-source stuff to join their program and one for the private stuff. Not sure if that's worth it, I doubt our IT department would be happy about this. ;)