0
About GitLab CI, forks and merge requests
Óscar García Amor edited this page 2022-07-15 07:50:35 +00:00

When a user forks our repository and adds commits to it, the CI pipeline is run in that user's space. This implies that if the user is newly created in GitLab and has not validated his or her account using a credit card, the CI pipeline will not run as the runners are disabled.

shared runners disabled

This limitation is GitLab's way of fighting cryptocurrency mining abuse.

Implications

If a user is in the situation described above, when he or she sends us a merge request, the pipeline will not be run because, as mentioned above, the user's runners will be disabled.

Solution

Even if the user is not validated, we can manually run the pipeline on the content of the merge request in our user space. We simply do the following:

  1. Revise the code.
  2. Make sure that code has been revised.
  3. Have you revised the merge request code? Do it again.
  4. Open the merge request.
  5. Go to Pipelines tab.
  6. Press button Run pipeline.

Again, make sure you have revised the code before run the pipeline as it will run in our user space and with our privileges.

To be considered

If the forked project sends the merge request using its own develop branch then when we press Run pipeline button the system will try to run the stages Translations and APK. This is because the branch is develop and, as the execution has been approved by us, it's using our project ID. There is nothing we can do against this, because if we prohibit these stages in a merge request then it will not work with our merge requests either.

However, there is a way to prevent these stages from running. Simply once we have approved the run of the pipeline, we can click on the forbidden icon so that the last two stages are not executed:

cancel stage

pipeline with stages cancelled

This will not happen if the merge request comes from any branch other than develop, which should always happen as it is one of the requirements to contribute.