feat(gitlab): support self-hosted GitLab via configurable API base#1235
Conversation
The GitLab features hard-coded https://gitlab.com/api/v4, so commit statuses, MR status comments, and inline lint discussions could only target gitlab.com. Add gitlab.resolve_api_base(env) and thread the resolved base through every gitlab.* call in the three features. Resolution precedence: 1. ASPECT_GITLAB_API_URL — explicit override (matches the existing ASPECT_GITLAB_* escape-hatch family). Accepts a full API base or a bare instance root, to which /api/v4 is appended; trailing slash trimmed. 2. CI_API_V4_URL — set natively by GitLab CI, so self-hosted GitLab CI needs no extra config. 3. https://gitlab.com/api/v4 — unchanged default. Adds resolve_api_base unit tests to lib/gitlab_test.axl.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 35cfdd32f5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| explicit = env.var("ASPECT_GITLAB_API_URL") or "" | ||
| if explicit: | ||
| return _normalize_api_base(explicit) | ||
| ci = env.var("CI_API_V4_URL") or "" | ||
| if ci: | ||
| return _normalize_api_base(ci) |
There was a problem hiding this comment.
Thread GitLab host into token minting
When these branches return a self-hosted API base, the subsequent feature code sends API calls to that host but still mints/reuses tokens through gitlab_token_cache.get_or_mint using only project_path, project_id, and roles. GitLab project paths and numeric IDs are only unique within an instance, so a self-hosted job for a path that also exists elsewhere can get or reuse a token for the wrong installation and then all calls made with this new api_base will 401. Please include the resolved host/API base in the auth payload and token-cache key before using it for self-hosted calls.
Useful? React with 👍 / 👎.
✨ Aspect Workflows Tasks📅 Mon Jun 15 23:29:42 UTC 2026 ✅ 12 successful tasks
⏱ Last updated Mon Jun 15 23:36:04 UTC 2026 · 📊 GitHub API quota 46/15,000 (0% used, resets in 54m) |
|
Docs for this (and the auth follow-up #1237): aspect-build/site#1072 |
Problem
The GitLab features hard-coded
https://gitlab.com/api/v4as the API base (DEFAULT_GITLAB_APIinlib/gitlab.axl). Everygitlab.*helper already accepted anapi_baseparameter, but no caller ever passed one — so commit statuses, the rolling MR status comment, and inline lint discussions could only ever targetgitlab.com. Self-hosted GitLab instances had no way in.Change
Add
gitlab.resolve_api_base(env)and thread the resolved base through everygitlab.*call in the three GitLab features.Resolution precedence:
ASPECT_GITLAB_API_URL— explicit override, matching the existingASPECT_GITLAB_*escape-hatch family ingitlab_detect.axl(for Aspect-Workflows runners on a non-GitLab CI host posting back to a self-hosted GitLab MR). Accepts either a full API base (https://self-hosted.gitlab.com/api/v4) or a bare instance root (https://self-hosted.gitlab.com), to which/api/v4is appended. A trailing slash is trimmed.CI_API_V4_URL— set natively by GitLab CI on every job and already points at the running instance's API, so self-hosted GitLab CI needs zero extra config.https://gitlab.com/api/v4— unchanged default when neither is set.Threaded through all three features:
feature/gitlab_commit_statuses.axl— the commit-status POSTfeature/gitlab_status_comments.axl— all six notes list/create/update/delete callsfeature/gitlab_lint_comments.axl—merge_requests.list_changes+ all five discussions calls (carried on theglcontext dict)Changes are visible to end-users: yes
Searched for relevant documentation and updated as needed: no — flagged for a follow-up docsite update
Breaking change (forces users to change their own code or config): no — default behavior on
gitlab.comis unchangedSuggested release notes appear below: yes
GitLab integrations (commit statuses, MR status comments, inline lint discussions) now work against self-hosted GitLab. Under GitLab CI this is automatic via
CI_API_V4_URL; elsewhere setASPECT_GITLAB_API_URLto your instance's API base.Test plan
resolve_api_baseunit cases tolib/gitlab_test.axl(default,CI_API_V4_URL, override precedence, bare-root/api/v4append, trailing-slash trim) plus the facade shape check.aspect dev test-gitlab-client→gitlab.axl smoke: OKaspect tests axl→790 tests passed(confirms all three edited feature files still load)