/** * GitLab integration — low-level API-wrapper skill. * * GitLab exposes a REST API (https://docs.gitlab.com/ee/api/) rooted at * `/api/v4`. Auth is a token sent in the `PRIVATE-TOKEN` header * (personal / project / group access token) or, for OAuth, an * `Authorization: Bearer ` header. * * This is the GitLab analog of github.js (the GitHub skill). It mirrors that * skill's structure exactly: a small `glFetch` helper as the single auth * chokepoint, a skill object ({ id, description, envKeys, promptFragment, * resolve, handleToolCall, tools[] }), tools that return JSON strings, and * graceful error messages instead of throws. * * Auth / config (env). Like linear.js (and UNLIKE jira.js / github.js whose * OAuth tokens are minted by the Zibby backend and fetched via * resolveIntegrationToken), the GitLab backend integration stores a pasted * Personal Access Token + an instanceUrl (see backend/src/handlers/gitlab.js: * { instanceUrl, accessToken }). The workflow-executor injects those into the * run as environment variables, which this skill reads: * * - GITLAB_TOKEN personal/project access token (api scope) — sent * in the PRIVATE-TOKEN header. This is the value the * backend stored as `accessToken`. * - GITLAB_OAUTH_TOKEN OAuth bearer token (optional; takes precedence; * sent as `Authorization: Bearer `) * - GITLAB_INSTANCE_URL the GitLab host the token belongs to, cloud OR * self-hosted — e.g. "https://gitlab.com" or * "https://gitlab.example.com". This is the backend's * `instanceUrl`. We append `/api/v4`. Defaults to * https://gitlab.com when unset, so cloud works with * just a token. SSRF on this URL is already validated * at the integration layer (validateInstanceUrl in * backend/src/handlers/gitlab.js); the skill just uses * the value it is handed. * - GITLAB_API_URL full `/api/v4` base override (rarely needed). If * set it wins over GITLAB_INSTANCE_URL. * - GITLAB_INSTANCES OPTIONAL. A JSON TABLE of several connected GitLab * servers, for a project whose selected repos span * more than one of them. ABSENT ⇒ the single-server * trio above is used exactly as before. See the * MULTI-INSTANCE ROUTING block below. * * When a backend GitLab OAuth handler lands, swap glFetch's auth + base to * resolveIntegrationToken('gitlab') — the tool surface stays the same. * * `requiresIntegration: INTEGRATIONS.GITLAB` makes GitLab a REQUIRED * integration for any workflow node that declares this skill (the marketplace * deploy gate blocks until GitLab is connected) — same as the github skill is * required for github_* tools. * * The GitLab vocabulary differs from GitHub: a "merge request" (MR) is the * GitHub "pull request"; an MR is addressed by (projectId, iid) where * `projectId` is either the numeric id or the URL-encoded full path * ("group/subgroup/repo") and `iid` is the per-project MR number. Both the * numeric id and the "namespace/project" path form are accepted everywhere a * projectId is taken (encodeProject handles the path-encoding). */ /** * Low-level GitLab REST helper. Throws on non-2xx, returns parsed JSON * (or raw text when opts.raw). Exported so a future gitlabAdapter (neutral * tracker layer) can reach endpoints the tools don't cover without * re-implementing auth — keep this the single auth chokepoint. * * @param {string} path API path beginning with `/` (relative to /api/v4), * or a full https:// url. * @param {{ method?: string, body?: object, raw?: boolean }} [opts] */ export declare function glFetch(path: any, opts?: any): Promise; export declare const gitlabSkill: any;