Merge request from GitLab self-hosted don't use the proper origin

[maxgalli]

Details

• Read the Docs project URL: https://readthedocs.org/projects/higgs-dna/
• Build URL (if applicable): https://readthedocs.org/projects/higgs-dna/builds/17593057/
• Read the Docs username (if applicable): https://readthedocs.org/profiles/magalli/

Expected Result

Build should succeed

Actual Result

Build fails

The problem is in the command

git fetch origin --force --tags --prune --prune-tags --depth 50

which should instead be

git fetch origin --force --tags --prune --prune-tags --depth 50 merge-requests/10/head:update-docs

for this to work. These instruction should in principle be build based on what is specified on the webhook, but I can't find a way to configure it correctly.

[stsewd]

Hi, this is because you are using a self-hosted version of GitLab, so RTD isn't able to format the origin properly

readthedocs.org/readthedocs/vcs_support/backends/git.py

Lines 162 to 172 in 46fa804

	if self.verbose_name and self.version_type == EXTERNAL:
	if self.project.git_provider_name == GITHUB_BRAND:
	cmd.append(
	GITHUB_PR_PULL_PATTERN.format(id=self.verbose_name)
	)
	if self.project.git_provider_name == GITLAB_BRAND:
	cmd.append(
	GITLAB_MR_PULL_PATTERN.format(id=self.verbose_name)
	)

We could try to fall back to guess from the integration type if the project is from a gitlab-like server, but even with that we won't be able to report the status back, only build the MR.

[jcfr]

We could try to fall back to guess from the integration type

In the context of open-source project hosted at gitlab.kitware.com (e.g https://docs.vtk.org), supporting build of merge request from self-hosted GitLab would be ideal.

In the current setup, despite of being self-hosted, we were able to add a GitLab Incoming Webhook.

Considering this, attempt to guess would not be needed because by definition, the merge request event are expected to be coming from the GitLab instance associated with the configured GitLab Incoming Webhook.

To move forward, as pointed out by @stsewd , we would need to update:

readthedocs.org/readthedocs/vcs_support/backends/git.py

Lines 164 to 172 in 524c24c

	if self.project.git_provider_name == GITHUB_BRAND:
	cmd.append(
	GITHUB_PR_PULL_PATTERN.format(id=self.verbose_name)
	)
	if self.project.git_provider_name == GITLAB_BRAND:
	cmd.append(
	GITLAB_MR_PULL_PATTERN.format(id=self.verbose_name)
	)

.. to check for the type of Integration setup in the project.

Questions

• In addition (or instead) of checking for the provider name, what about having the fetch be conditional on the Integration type ?

Example of integration / https://docs.vtk.org

[jcfr]

what about having the fetch be conditional on the Integration type ?

Answering my own question

Step 1

Since a given project can have multiple integration, we would need to know which integration was responsible for triggering a specific build.

This would allow to at least successfully trigger the build.

On the merge request side, it would then already be an improvement to have a (soon to be valid) preview URL available.

Step 2

In addition of knowing the integration type triggering a specific build, in the context of the GitLab integration, we could also pass down the value associated with X-Gitlab-Instance header as well as an API token that would be configured in the UI.

[Kilidsch]

Hello everyone,

Since we are affected by this as well, I wanted to ask whether there is any idea of how this issue could be resolved?

Would an option like #10397 rebased onto the current main be acceptable or is another solution desired?