GitLab Operations & Permissions
The project lives on Drupal.org’s self-managed GitLab at git.drupalcode.org. Not every GitLab operation behaves the way it would on gitlab.com: some work fine over the REST API or CLI, some are intercepted by Drupal.org and have to go through the GitLab web UI (or a site admin), and some need maintainer-level access on the project. This page summarizes what we have actually confirmed while working on the project.
What works where
Section titled “What works where”Git & code access
Section titled “Git & code access”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Clone & push code | SSH — git@git.drupal.org | Yes | Push access (Developer / “Write to VCS”) |
| Push over HTTPS | HTTPS | No (401) | — use SSH instead |
API, CLI & issues
Section titled “API, CLI & issues”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Read data (projects, pipelines, jobs, artifacts, issues) | REST API GET (token) or glab | Yes | Any authenticated user |
| Validate CI config | REST API POST /ci/lint or glab | Yes | Any authenticated user |
| Create & edit issues | REST API POST/PUT /issues or glab | Yes | Any authenticated user |
CI/CD pipelines
Section titled “CI/CD pipelines”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Run a pipeline on demand | REST API POST /pipeline | No (301 → drupal.org/git-error) | Use GitLab UI: Build → Pipelines → Run pipeline |
| Create a pipeline schedule | REST API | No (blocked, same pattern) | GitLab UI: Build → Pipeline schedules (maintainer) |
Branches & project settings
Section titled “Branches & project settings”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Change the default branch | GitLab UI (self-service); API is blocked | Yes, via UI | Maintainer |
| Set protected branches / push rules | REST API | No (301) | drupal.org site admins (beyond a project maintainer) |
Merge requests
Section titled “Merge requests”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Merge an MR (unprotected branch) | GitLab UI / API | Yes | Developer (“Write to VCS”) |
| Merge to a protected branch | GitLab UI | Yes | Maintainer |
Access & permissions
Section titled “Access & permissions”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Manage Epics | GitLab UI / API | No (no permission on the shared project group) | Use a tracking issue with a checklist as the epic-equivalent |
| Grant contributors more access | drupal.org project → Maintainers page (syncs to GitLab roles) | Yes | Maintainer / owner |
Local tooling
Section titled “Local tooling”| Action | Channel | Works today? | Access needed |
|---|---|---|---|
| Enable the pre-commit / pre-push hooks | local lefthook install (see Developer Setup) | Yes | None (per clone) |
Auth / token
Section titled “Auth / token”API calls need a GitLab personal access
token, sent as
a PRIVATE-TOKEN header. glab uses the same
token, pointed at git.drupalcode.org rather than gitlab.com.
SSH host gotcha
Section titled “SSH host gotcha”The Git SSH host is git.drupal.org, not git.drupalcode.org (the latter is
the web-UI host only). Using the wrong host produces a port-22 timeout that looks
like a firewall block rather than an authentication error. HTTPS pushes are rejected
with a 401, so SSH is the only working push channel. See
Developer Setup for the clone command.
What’s blocked and why
Section titled “What’s blocked and why”Several write operations return 301 → https://www.drupal.org/git-error because
Drupal.org manages those settings itself, not raw GitLab. Confirmed blocked over the
API: triggering pipelines, and project-settings mutations (changing the default
branch, setting protected branches, and push rules). Do these in the GitLab web UI
instead, or — for infra-level settings such as protected branches and push rules —
ask a Drupal.org site admin.
What works via API
Section titled “What works via API”Reads, CI lint, and issue create/edit all work over the API. Sibling issues in this epic were revised via the API. See Contribution Standards for the issue and commit conventions those calls follow.
Maintainer level
Section titled “Maintainer level”Drupal maps project roles to GitLab roles:
- “Write to VCS” → Developer — push, and merge unprotected MRs.
- Adding “Administer maintainers” → Maintainer — project settings, merging to protected branches, and changing the default branch.
Grant these on the project’s Maintainers page on Drupal.org; they sync to
GitLab. Epics are the exception: they need permissions on the shared project
group that individual project maintainers don’t have — hence the checklist-issue
workaround listed in the table above.
glab works for the API-allowed operations
(reads, issues, CI lint) with the same token. The same Drupal.org write-blocks
apply, so glab cannot trigger pipelines or change protected settings either.
Groups Initiative — Rebuilding Drupal's community Groups platform on Modern Drupal.