GitLabCI does not allow MRs from forks opened by non-members to run in the parent project

Enable testing on project forks

We currently don’t enable testing on forks for cost savings. Having a merge request signals that work is ready to review and test. GitLab CI on forks would be testing on commit, which would add up when people make incremental commits.

It looks like scheduled pipelines are configured in the GitLab UI, outside of .gitlab-ci.yml, so I don’t think they should transfer to forks. That would have to be verified. If forks inherit their parent project schedule, that’d start multiplying the CI resources used.

https://git.drupalcode.org/help/ci/pipelines/merge_request_pipelines.md mentions a few security considerations for both resolutions. I hope most aren’t relevant for Drupal’s use case. We do have people storing important secrets in CI variables, like API keys for publishing to NPM.

Added “Evaluate security tradeoffs of either resolution” to the issue summary.

In the issue summary, under "The only ways for an MR opened by a non-member to run is:" the second bullet point says

For a project member to 'run pipeline' on the merge request manually.

I'm not sure this is right, at least this is not what I experience. I'm the contrib maintainer, pipelines for my own MRs run, but for MRs created by non-members yes the 'run pipeline' button exists for me, but clicking it does not trigger a pipeline to run.

#3359327-12: ESLINT does not respect the 'ignore' files → #12 and #13 gives some background to this.

For info, @drumm has fixed the problem I reported in #4, and maintainers can now run pipelines created by non-members. Thank you.

I can verify that scheduled pipelines dont transfer to the forks.

We currently don’t enable testing on forks for cost savings.

I dont think we gitlab_templates allow pipelines to run on a commit outside of an MR or default branch. If it does, we can easily disallow that. I dont think anyone wants to increase the number of pipelines that are run.

Evaluate security tradeoffs of either resolution

Pipelines in forks is more secure, as secrets are not available to malicious code running MR pipelines. Thats also how Github/Travis/CircleCI work, so we would be in good company.

Only testing the default branch is surprising. Drupal.org projects often maintain more than one branch. Opened #3361330: Test branches other than default →

A suggested solution from @fjgarlin:

…
So the rule can be changed from:
if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
To (untested):
if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PROJECT_ROOT_NAMESPACE == "project"
…

hestenet → credited fjgarlin → .

Committed: https://git.drupalcode.org/project/gitlab_templates/-/commit/65f25ebba78...

Now we'll need to also incorporate the changes in: #3361330: Test branches other than default → but we can do that over in that issue..

Whoops - this issue isn't just for the branch testing config, it's also for finalizing the decision the solution to actually get MRs running from forks - reopening.

However - I think the change committed above should prevent the forks from doing a bunch of unnecessary automatic testing. They should now only test on manual trigger or MR.

The bulk update will look a lot like ✨ Enable GitLab CI, wiki & snippets for projects, except sandboxes Fixed

Thanks for doing this. Next time a non-maintainer creates a MR I will report back to let you know if the pipeline ran immediately.

Yes, this has been deployed, and the existing issue forks were bulk updated on Friday. The code used for the bulk update was

$client = versioncontrol_gitlab_get_client()->getHttpClient();
$result = (new EntityFieldQuery())->entityCondition('entity_type', 'drupalorg_issue_fork')
->execute();
foreach (array_keys($result['drupalorg_issue_fork']) as $gitlab_project_id) {
  print $gitlab_project_id . ' ';
  $client->put('projects/' . $gitlab_project_id, ['Content-type' => 'application/x-www-form-urlencoded'], drupal_http_build_query([
    'jobs_enabled' => 'true',
    'shared_runners_enabled' => 'true',
  ]));
}

And we now have integrity checks ensuring this stays enabled, so everything is done here.

Automatically closed - issue fixed for 2 weeks with no activity.

As promised I would report back, a non-maintainer has created a MR and the pipeline ran without my intervention
https://git.drupalcode.org/project/scheduler/-/merge_requests/100