fix(gitlab): preserve instance subpath when importing MRs

[ydflow]

Summary

With GITLAB_URL=https://host/gitlab, importing https://host/gitlab/g/sub/repo/-/merge_requests/7 currently requests /api/v4/projects/gitlab%2Fg%2Fsub%2Frepo/.... The documented deployment prefix is dropped from the API base and incorrectly included in the project id, so MR import fails for a sub-path instance.

Keep the configured instance path in the API base and strip that prefix from the project path. Refuse an MR outside the configured instance path before making a request. Preserve nested groups and the custom GITLAB_API_PREFIX. Update the bilingual provider guide and troubleshooting reference.

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Test Plan

• npm run build
• npx tsc --noEmit
• npm run lint
• npx vitest run gitlab-provider: 62 passed.
• git diff --check
• Full repository unit suite and live GitLab instance (left to CI/environment).

All three new cases fail against the unchanged upstream runtime at 27a026f: the two API-prefix cases show the wrong URLs, and the outside-root case reaches fetch instead of refusing it. The other 59 tests pass on that baseline.

Refreshed onto upstream 450be2aa before submission; build, typecheck, lint, the 62 tests, and both built-CLI cases passed again on head 4e5be8da.

Real CLI verification after build

Windows, Node 24.19.0; isolated HOME/USERPROFILE; a loopback HTTP server simulating GitLab; a dummy token; a fake claude returning fixed Markdown. No real credentials, model calls, remote writes, or GitLab account are required.

GITLAB_URL=http://127.0.0.1:<port>/gitlab/
GITLAB_TOKEN=<fixture-token>
GITLAB_API_PREFIX=api/v4  (then api/gateway)

node dist/index.js ci extract-mr --url http://127.0.0.1:<port>/gitlab/g/sub/repo/-/merge_requests/7 --mode write --team-repo <fixture-repo> --dry-run

Both runs exit 0 and report MR data fetched. The server sees exactly the metadata, commits, and changes requests under:

/gitlab/api/v4/projects/g%2Fsub%2Frepo/merge_requests/7...
/gitlab/api/gateway/projects/g%2Fsub%2Frepo/merge_requests/7...

The fake AI invocation marker exists after each successful fetch. Unit tests additionally verify the returned commits and diff. The CLI fixture validates request routing through the real command against a local server, not a live GitLab deployment.

Related Issues

Found through source inspection of the documented sub-path deployment support. #450 added custom API prefixes; this fix preserves that feature while handling the separate instance root. No open PR addressing this MR path split was found. #1122 changes import orchestration and does not modify this provider fetcher.

Notes for Reviewers

Reuses the existing gitlabBaseUrl() configuration resolver, keeping its URL validation and the existing configured-host guard. The MR URL still supplies the request scheme and host after that guard. No clone, authentication, or persisted config format changes. Independent of #1149 and the GitHub HTTP-status fix; the shared guide edits are in separate provider sections.

Shares documentation files with #1150, but changes different sections. Both local merge orders were checked on base 450be2aa at heads e6fde993 and 4e5be8da: no conflicts and the same final tree. Neither runtime fix depends on the other.

Prepared with assistance from an AI coding agent.

[github-actions]

No findings confidently identified in the specified PR diff.

The PR description provides sufficient testing evidence: build, typecheck, lint, 62 provider tests, and two built-CLI runs against a loopback GitLab fixture covering default and custom API prefixes. This satisfies the real-CLI verification requirement; a live GitLab deployment and full provider × agent matrix are not required.

Review was read-only; I did not run, build, or install PR code.