How to Integrate Retool with GitLab

Navigate to the Resources tab in Retool's left navigation. Click Add Resource in the top-right corner. In the resource type picker, locate the Development section and click GitLab. The GitLab resource configuration form opens. In the 'Resource name' field, enter a descriptive name such as 'GitLab Prod' or 'GitLab Engineering'. For self-managed instances, update the 'Base URL' field from the default 'https://gitlab.com' to your instance URL (for example, 'https://gitlab.yourcompany.com'). In the 'Personal Access Token' field, paste the token you created in GitLab. The token must have the 'api' scope to allow reading and writing across repositories, merge requests, and pipelines. If you only need read access, a token with the 'read_api' scope is sufficient and follows the principle of least privilege. Leave all other fields at their defaults. Click Save Changes. Retool will attempt a test connection by querying the GitLab API with your token. A green Connected status confirms the credentials are valid. If you manage separate GitLab instances for engineering and security teams, or separate environments (internal dev vs. external partners), create one Resource per instance. You can switch between resources in the query editor dropdown without duplicating app logic.

Open your Retool app and navigate to the Code panel at the bottom. Click + New query. From the Resource dropdown, select your GitLab resource. The query editor presents a GitLab-specific action picker. From the 'Action' dropdown, select 'List Merge Requests'. Retool exposes input fields for the query parameters: - 'Project ID': Enter the numeric project ID (e.g., 12345678) or leave blank and use the 'Group ID' field to query all projects in a group. - 'State': Set to 'opened' to show only active MRs. Other options are 'closed', 'locked', and 'merged'. - 'Target branch': Optionally filter to 'main' or 'production' if you want to focus on release-critical MRs. - 'Per page': Set to 50 or 100 to retrieve more results per call. Name the query 'getMergeRequests'. Leave 'Run query on page load' set to On so the data loads automatically. Switch to the Canvas view. Drag a Table component from the Component panel onto the canvas. In the Table's Data property, enter `{{ getMergeRequests.data }}`. The Table will auto-generate columns from the response. In the Column settings, choose to show: title, author.name, target_branch, state, web_url (as a hyperlink), created_at, and detailed_merge_status. Use the Column display settings to rename them with user-friendly headers. Add a mapped column 'Pipeline Status' bound to `{{ row.head_pipeline?.status || 'none' }}` with conditional coloring: green for 'success', red for 'failed', yellow for 'running'.

1// Transformer: reshape merge request data for display
2const mrs = data;
3return mrs.map(mr => ({
4  id: mr.iid,
5  title: mr.title,
6  author: mr.author?.name || 'Unknown',
7  target_branch: mr.target_branch,
8  status: mr.detailed_merge_status,
9  pipeline: mr.head_pipeline?.status || 'none',
10  created: new Date(mr.created_at).toLocaleDateString(),
11  url: mr.web_url,
12  reviewers: (mr.reviewers || []).map(r => r.username).join(', ')
13}));

With merge requests displayed, add a pipeline monitoring section to give operators visibility into build health. Create a new query: click + New query, select your GitLab resource, and from the 'Action' dropdown choose 'List Pipelines'. Set 'Project ID' to `{{ projectSelect.value }}` so operators can switch between projects using a dropdown. Set 'Per page' to 20 and 'Order by' to 'updated_at' and 'Sort' to 'desc' so the most recent pipelines appear first. Name the query 'getPipelines'. On the canvas, add a Select component named 'projectSelect'. Populate its Options manually with project IDs and display names for your key repositories, or bind it to a separate GitLab 'List Projects in Group' query that returns all projects in your namespace. Drag a second Table component below the MR table. Set its Data to `{{ getPipelines.data }}`. Configure columns for: id, status (with color badges), ref (branch name), sha (shortened to first 8 chars via a column transformer: `{{ row.sha?.substring(0,8) }}`), created_at, duration (formatted as seconds), and a direct link to the pipeline. Add a Button component labeled 'Retry Pipeline'. In its Event Handler, wire it to a new query: Action = 'Retry Pipeline', Project ID = `{{ projectSelect.value }}`, Pipeline ID = `{{ pipelineTable.selectedRow.id }}`. This lets operators retry failed pipelines without leaving Retool. Add a second Button labeled 'Cancel Pipeline' wired to an 'Cancel Pipeline' action query — useful for stopping runaway builds that are consuming CI minutes.

1// Transformer: summarize pipeline stats for a Chart component
2const pipelines = data;
3const counts = pipelines.reduce((acc, p) => {
4  acc[p.status] = (acc[p.status] || 0) + 1;
5  return acc;
6}, {});
7return Object.entries(counts).map(([status, count]) => ({ status, count }));

Engineering managers often need to track GitLab issues alongside code changes. Create a new query: select your GitLab resource, Action = 'List Issues', and set parameters: - 'Scope': 'all' to include all group issues. - 'State': `{{ issueStateSelect.value }}` to allow filtering opened/closed. - 'Labels': `{{ labelsInput.value }}` so operators can filter by label (e.g., 'priority::high' or 'backend'). - 'Assignee username': `{{ assigneeInput.value }}` for per-person views. Name the query 'getIssues'. On the canvas, add a third section labeled 'Issues' with: - A Select component 'issueStateSelect' with options 'opened' and 'closed'. - A Text Input 'labelsInput' for label filtering. - A Text Input 'assigneeInput' for assignee filtering. - A Table component bound to `{{ getIssues.data }}` showing title, project (from references.full), assignees, labels, due_date, and a web_url link. For cross-project issue search, set 'Group ID' instead of 'Project ID' in the getIssues query — GitLab's API supports group-level issue listing that aggregates across all sub-groups and projects. Add a 'Create Issue' form using Retool's Form component. Configure a GitLab 'Create Issue' query bound to the form fields (project dropdown, title input, description text area, labels input). Wire the form's Submit button to the create query, with the getIssues query triggered on success to refresh the list.

1// Transformer: extract unique assignees from issues list for a filter dropdown
2const issues = data;
3const assignees = new Set();
4issues.forEach(issue => {
5  (issue.assignees || []).forEach(a => assignees.add(a.username));
6});
7return Array.from(assignees).sort().map(u => ({ label: u, value: u }));

One of the most powerful Retool–GitLab integrations is adding governance to manual deployment jobs. GitLab CI/CD allows pipeline jobs to be marked as 'manual' — they pause until a human explicitly triggers them. Retool can surface these pending manual jobs and add an approval layer before triggering. Create a query: Action = 'List Pipeline Jobs', Project ID = `{{ projectSelect.value }}`, Pipeline ID = `{{ pipelineTable.selectedRow.id }}`. Name it 'getPipelineJobs'. Filter for manual jobs using a Transformer: `return data.filter(job => job.status === 'manual');` Display this in a Table component 'jobsTable' showing job name, stage, status, and environment. Add a 'Trigger Job' button. In its Event Handler, set the action to trigger a new GitLab query: - Action: 'Play Job (Trigger Manual Job)' - Project ID: `{{ projectSelect.value }}` - Job ID: `{{ jobsTable.selectedRow.id }}` Before wiring this directly, add a Confirmation Modal: enable 'Show confirmation before running' in the button's event handler and set the confirmation message to: 'Are you sure you want to trigger job {{ jobsTable.selectedRow.name }} in {{ jobsTable.selectedRow.environment }}? This will deploy to production.' Add an on-success handler that writes an audit log to Retool Database or PostgreSQL: `{ triggered_by: current_user.email, job_id: jobsTable.selectedRow.id, job_name: jobsTable.selectedRow.name, triggered_at: new Date().toISOString() }` For complex multi-stage deployment workflows involving multiple GitLab projects and Slack notifications, RapidDev's team can help design a Retool Workflow that orchestrates GitLab triggers with approval gates and status notifications.

1// Transformer: filter pipeline jobs to show only manual/playable jobs
2const jobs = data;
3return jobs
4  .filter(job => job.status === 'manual')
5  .map(job => ({
6    id: job.id,
7    name: job.name,
8    stage: job.stage,
9    status: job.status,
10    environment: job.environment?.name || 'N/A',
11    created_at: new Date(job.created_at).toLocaleString()
12  }));