Get started with a free trial today
Already have an account? Sign in
Stitch’s GitLab integration replicates data using theGitLab REST API. Refer to theSchema section for a list of objects available for replication.
A high-level look at Stitch's GitLab (v1) integration, including release status, useful links, and the features supported in Stitch.
| STITCH | |||
| Release status | Released on March 1, 2017 | Supported by | |
| Stitch plan | Standard | API availability | Available |
| Singer GitHub repository | |||
| REPLICATION SETTINGS | |||
| Anchor Scheduling | Supported | Advanced Scheduling | Supported |
| Table-level reset | Unsupported | Configurable Replication Methods | Unsupported |
| DATA SELECTION | |||
| Table selection | Unsupported | Column selection | Unsupported |
| Select all | Unsupported | ||
| TRANSPARENCY | |||
| Extraction Logs | Supported | Loading Reports | Supported |
To set up GitLab in Stitch, you need:
Access to any projects you want to replicate data from. Stitch will only be able to access the same projects as the user who creates the integration.
Stitch. This will allow you to easily identify what application is using the token.On the Stitch Dashboard page, click theAdd Integration button.
Click theGitLab icon.
Enter a name for the integration. This is the name that will display on the Stitch Dashboard for the integration; it’ll also be used to create the schema in your destination.
For example, the name “Stitch GitLab” would create a schema calledstitch_gitlab in the destination.Note: Schema names cannot be changed after you save the integration.
https://gitlab.com/api/v4.In theProjects andGroups to Track fields, you’ll enter the projects and/or groups you want to track as aspace-separated list.
For example:stitchdata/group-a, orstitchdata/project-a stitchdata/project-b
Note: A value for one of these fields must be provided. Additionally, the way you define these settings determines how some data is replicated:
The Sync Historical Data setting defines the starting date for your GitLab integration. This means that dataequal to or newer than this date will be replicated to your data warehouse.
Change this setting if you want to replicate data beyond GitLab’s default setting of1 year. For a detailed look at historical replication jobs, check out theSyncing Historical SaaS Data guide.
In theReplication Frequency section, you’ll create the integration’sreplication schedule. An integration’s replication schedule determines how often Stitch runs a replication job, and the time that job begins.
GitLab integrations support the following replication scheduling methods:
Advanced Scheduling using Cron (Advanced or Premium plans only)
To keep your row usage low, consider setting the integration to replicate less frequently. See theUnderstanding and Reducing Your Row Usage guide for tips on reducing your usage.
After you finish setting up GitLab, itsSync Status may show asPending on either the Stitch Dashboard or in the Integration Details page.
For a new integration, aPending status indicates that Stitch is in the process of scheduling the initial replication job for the integration.This may take some time to complete.
Initial replication jobs with Anchor Scheduling
If using Anchor Scheduling, an initial replication job may not kick off immediately. This depends on the selected Replication Frequency and Anchor Time. Refer to theAnchor Scheduling documentation for more information.
The first seven days of replication, beginning when data is first replicated, are free. Rows replicated from the new integration during this time won’t count towards your quota. Stitch offers this as a way of testing new integrations, measuring usage, and ensuring historical data volumes don’t quickly consume your quota.
Schemas and versioning
Schemas and naming conventions can change from version to version, so we recommend verifying your integration’s version before continuing.
The schema and info displayed below is forversion 1 of this integration.
This is the latest version of the GitLab integration.
Table and column names in your destination
Depending on your destination, table and column names may not appear as they are outlined below.
For example: Object names are lowercased in Redshift (CusTomERs >customers), while case is maintained in PostgreSQL destinations (CusTomERs >CusTomERs). Refer to theLoading Guide for your destination for more info.
Thebranches table contains high-level info about repository branches in your projects.
Note: To replicate branch data, you must set this table and theprojects table to replicate. Data for this table will only be replicated when the associated project (in theprojects table) is also updated.
Key-based Incremental | |
Primary Keys | project_id name |
| Useful links |
| Join branches with | on |
|---|---|
| commits | branches.project_id = commits.project_id branches.commit_id = commits.id |
| issues | branches.project_id = issues.project_id |
| milestones | branches.project_id = milestones.project_id |
| projects | branches.project_id = projects.project_id |
commit_id STRING |
developers_can_merge BOOLEAN |
developers_can_push BOOLEAN |
merged BOOLEAN |
name STRING |
project_id INTEGER |
protected BOOLEAN |
Thecommits table contains info about repository commits in a project.
Note: To replicate commit data, you must set this table and theprojects table to replicate. Data for this table will only be replicated when the associated project (in theprojects table) is also updated.
Key-based Incremental | |
Primary Key | id |
| Useful links |
| Join commits with | on |
|---|---|
| branches | commits.project_id = branches.project_id commits.id = branches.commit_id |
| issues | commits.project_id = issues.project_id |
| milestones | commits.project_id = milestones.project_id |
| projects | commits.project_id = projects.project_id |
allow_failure BOOLEAN |
author_email STRING |
author_name STRING |
committer_email STRING |
committer_name STRING |
created_at DATE-TIME |
id STRING |
message STRING |
project_id INTEGER |
short_id STRING |
title STRING |
Thegroups table contains info about the groups in your GitLab account.
Full Table | |
Primary Key | id |
| Useful links |
avatar_url STRING | |
description STRING | |
full_name STRING | |
full_path STRING | |
id INTEGER | |
lfs_enabled BOOLEAN | |
name STRING | |
path STRING | |
projects ARRAY
| |
request_access_enabled BOOLEAN | |
visibility_level INTEGER | |
web_url STRING |
Theissues table contains info about issues contained within projects.
Key-based Incremental | |
Primary Key | id |
Replication Key | updated_at |
| Useful links |
| Join issues with | on |
|---|---|
| branches | issues.project_id = branches.project_id |
| commits | issues.project_id = commits.project_id |
| milestones | issues.project_id = milestones.project_id issues.milestone_id = milestones.id |
| projects | issues.project_id = projects.project_id |
assignee_id INTEGER |
author_id INTEGER |
confidential BOOLEAN |
created_at DATE-TIME |
description STRING |
due_date STRING |
id INTEGER |
iid INTEGER |
labels ARRAY |
milestone_id INTEGER |
project_id INTEGER |
state STRING |
subscribed BOOLEAN |
title STRING |
updated_at DATE-TIME |
user_notes_count INTEGER |
web_url STRING |
Themilestones table contains info about project milestones.
Note: To replicate milestone data, you must set this table and theprojects table to replicate. Data for this table will only be replicated when the associated project (in theprojects table) is also updated.
Key-based Incremental | |
Primary Key | id |
Replication Key | updated_at |
| Useful links |
created_at DATE-TIME |
description STRING |
due_date STRING |
group_id INTEGER |
id INTEGER |
iid INTEGER |
project_id INTEGER |
start_date STRING |
state STRING |
title STRING |
updated_at DATE-TIME |
Theprojects table contains info about specific projects.
Key-based Incremental | |
Primary Key | id |
Replication Key | last_activity_at |
| Useful links |
| Join projects with | on |
|---|---|
| branches | projects.project_id = branches.project_id |
| commits | projects.project_id = commits.project_id |
| issues | projects.project_id = issues.project_id |
| milestones | projects.project_id = milestones.project_id |
| users | projects.creator_id = users.id |
approvals_before_merge INTEGER | ||||
archived BOOLEAN | ||||
avatar_url STRING | ||||
builds_enabled BOOLEAN | ||||
container_registry_enabled BOOLEAN | ||||
created_at DATE-TIME | ||||
creator_id INTEGER | ||||
default_branch STRING | ||||
description STRING | ||||
forks_count INTEGER | ||||
http_url_to_repo STRING | ||||
id INTEGER | ||||
issues_enabled BOOLEAN | ||||
last_activity_at DATE-TIME | ||||
lfs_enabled BOOLEAN | ||||
merge_requests_enabled BOOLEAN | ||||
name STRING | ||||
name_with_namespace STRING | ||||
namespace OBJECT
| ||||
only_allow_merge_if_all_discussions_are_resolved BOOLEAN | ||||
only_allow_merge_if_build_succeeds BOOLEAN | ||||
open_issues_count INTEGER | ||||
owner_id INTEGER | ||||
path STRING | ||||
path_with_namespace STRING | ||||
permissions OBJECT
| ||||
public BOOLEAN | ||||
public_builds BOOLEAN | ||||
request_access_enabled BOOLEAN | ||||
shared_runners_enabled BOOLEAN | ||||
shared_with_groups ARRAY
| ||||
snippets_enabled BOOLEAN | ||||
ssh_url_to_repo STRING | ||||
star_count INTEGER | ||||
tag_list ARRAY | ||||
visibility_level INTEGER | ||||
web_url STRING | ||||
wiki_enabled BOOLEAN |
Theusers table contains info about the users in your GitLab account.
Full Table | |
Primary Key | id |
| Useful links |
| Join users with | on |
|---|---|
| projects | users.id = projects.creator_id |
avatar_url STRING |
id INTEGER |
name STRING |
state STRING |
username STRING |
web_url STRING |
| Related | Troubleshooting |
Did this article help? If you have questions or feedback, feel free tosubmit a pull request with your suggestions,open an issue on GitHub, orreach out to us.