Allow to post the build status to a commit in a fork
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Steps to reproduce
- Set up an external CI (Jenkins, AppVeyor, ...) on the target repository by setting a webhook on a merge request.
- Create a merge request from a fork.
- The external CI is not allowed to set the build status for the last commit in the fork, unless the target's owner is a Developer of the fork repository.
This is a severe limitation which decreases usability of GitLab for open source development, where the fork model is common, and the fork owners are not Developers on the target repository. As an example, on GitHub the CIs can post commit statuses to the Pull Request, and so anybody who forks an open source project and submits a Pull Request will get the pull request tested and the status will get properly set.
Proposals to fix this
Proposal 1 (always allow in forks)
Always allow "members who can merge to the target branch" (and the associated API tokens) to post the build status to a commit in a fork.
Proposal 2 (configurable, by default not changing the current behavior)
- Allow to set the status on the fork if "Allow commits from members who can merge to the target branch." is checked by the fork's owner when submitting the MR.
- Add an option to the target repository's settings: "Turn 'Allow commits from members who can merge to the target branch.' on by default", this will be off by default (not to change the current behavior), but if checked by the target's owner, then when the fork's owner submits an MR, the option "Allow commits from members who can merge to the target branch." is checked, so the fork's owner doesn't need to do anything, just submit the MR and the commit status will be set by the CI. The fork's owner can still uncheck the box manually before submitting the MR if that's what they want.
Proposal 3 (set status in the target repository commit)
GitHub allows to set the commit status on both the fork (if you have access -- which is the current GitLab behavior) and the target repository for the same commit (GitLab currently does not allow it). I think that is the cleanest solution which does not require changing any permissions. The target repository already has access to the merge commit, so it might as well allow setting a commit status on it. However this proposal might need https://gitlab.com/gitlab-org/gitlab-ee/issues/9713 to be implemented first.
Notes
-
The fix to this issue using Proposal 1 and 2 should be just a (hopefully relatively simple) permission change for posting commit statues (https://docs.gitlab.com/ce/api/commits.html#post-the-build-status-to-a-commit), not a completely new Enterprise feature for GitLab-CI in the context of merge requests as in https://gitlab.com/gitlab-org/gitlab-ee/issues/9713.
-
The Proposal 3 might be the way to go, but that would require GitLab to handle pipelines/commits for merge requests, which is in development in https://gitlab.com/gitlab-org/gitlab-ee/issues/9713.
-
Fixing this issue would bring GitLab on par with GitHub for open source projects, and GitLab can still have extra Enterprise features for GitLab-CI that go way beyond a simple commit status update.
-
Fixing this will provide either fixes or solid workarounds for the following issues: