This integration is powered by Singer's GitLab tap. For support, visit the GitHub repo or join the Singer Slack.
GitLab integration summary
Stitch’s GitLab integration replicates data using the GitLab REST API. Refer to the Schema section for a list of objects available for replication.
GitLab feature snapshot
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 |
Connecting GitLab
GitLab setup requirements
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.
Step 1: Create a GitLab token
- Sign into your GitLab account.
- Click the user menu (your icon) > Settings.
- Click the Access Tokens tab.
- In the Name field, enter
Stitch
. This will allow you to easily identify what application is using the token. - In the Scopes section, check the api box. This will allow Stitch to access your API and replicate your GitLab data.
- Click Create Personal Access Token.
- The new Access Token will display at the top of the page. Copy the token before navigating away from the page - GitLab won’t display it again.
Step 2: Add GitLab as a Stitch data source
- Sign into your Stitch account.
-
On the Stitch Dashboard page, click the Add Integration button.
-
Click the GitLab 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 called
stitch_gitlab
in the destination. Note: Schema names cannot be changed after you save the integration. - In the API URL field, enter
https://gitlab.com/api/v3
- In the Private Token field, paste the Personal Access Token you created in the previous section.
-
In the Projects and Groups to Track fields, you’ll enter the projects and/or groups you want to track as a space-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:
- If groups are provided but projects aren’t, all group projects will be replicated.
- If groups and projects are provided, the selected projects of the listed groups will be replicated.
- If projects are provided but groups aren’t, all listed projects will be replicated.
Step 3: Define the historical replication start date
The Sync Historical Data setting defines the starting date for your GitLab integration. This means that:
- For tables using Key-based Incremental Replication, data equal to or newer than this date will be replicated to your destination.
- For tables using Full Table Replication, all data - including records that are older, equal to, or newer than this date - will be replicated to your destination.
Change this setting if you want to replicate data beyond GitLab’s default setting of 1 year. For a detailed look at historical replication jobs, check out the Syncing Historical SaaS Data guide.
Step 4: Create a replication schedule
In the Replication Frequency section, you’ll create the integration’s replication 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 the Understanding and Reducing Your Row Usage guide for tips on reducing your usage.
Initial and historical replication jobs
After you finish setting up GitLab, its Sync Status may show as Pending on either the Stitch Dashboard or in the Integration Details page.
For a new integration, a Pending 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 the Anchor Scheduling documentation for more information.
Free historical data loads
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.
GitLab table reference
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 for version 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 the Loading Guide for your destination for more info.
branches
Replication Method : |
Key-based Incremental |
Replication Key |
projects.last_activity_at |
Primary Key |
project_id : name |
API endpoint : |
The branches
table contains high-level info about repository branches in your projects.
Note: To replicate branch data, you must set this table and the projects
table to replicate. Data for this table will only be replicated when the associated project (in the projects
table) is also updated.
project_id
The ID of the project associated with the branch. Reference: |
name
The name of the branch. |
merged
Indicates if the branch has been merged. |
protected
Indicates if the branch is protected. |
developers_can_push
Indicates if developers can push to the branch. |
developers_can_merge
Indicates if developers can merge. |
commit_id
The ID of the commit. Reference: |
commits
Replication Method : |
Key-based Incremental |
Replication Key |
projects.last_activity_at |
Primary Key |
id |
API endpoint : |
The commits
table contains info about repository commits in a project.
Note: To replicate commit data, you must set this table and the projects
table to replicate. Data for this table will only be replicated when the associated project (in the projects
table) is also updated.
id
The commit ID. Reference: |
created_at
The time the commit was created. |
project_id
The ID of the project associated with the commit. Reference: |
short_id
The short ID of the commit. |
title
The title of the commit. |
author_name
The name of the commit’s author. |
author_email
The email of the commit’s author. |
committer_name
The name of the committer. |
committer_email
The email address of the committer. |
message
The commit message. |
allow_failure
Indicates if failures are allowed. |
issues
Replication Method : |
Key-based Incremental |
Replication Key |
updated_at |
Primary Key |
id |
API endpoint : |
The issues
table contains info about issues contained within projects.
id
The issue ID. Reference: |
updated_at
The time the issue was last updated. |
project_id
The ID of the project associated with the issue. Reference: |
milestone_id
The ID of the milestone associated with the issue. Reference: |
author_id
The ID of the issue’s author. |
assignee_id
The ID of the user who is assigned to the issue. |
description
The issue’s description. |
state
The state of the issue. Possible values are |
iid
The IID of the issue. |
labels
A list of labels applied to the issue. |
title
The title of the issue. |
created_at
The time the issue was created. |
subscribed
Indicates if the authenticating user (the user who created the integration in Stitch) is subscribed to the issue. |
user_notes_count
The count of notes in the issue. |
due_date
The date the issue is due by. |
web_url
The URL of the issue. |
confidential
Indicates if the issue is confidential. |
milestones
Replication Method : |
Key-based Incremental |
Replication Key |
updated_at |
Primary Key |
id |
API endpoint : |
The milestones
table contains info about project milestones.
Note: To replicate milestone data, you must set this table and the projects
table to replicate. Data for this table will only be replicated when the associated project (in the projects
table) is also updated.
id
The milestone ID. Reference: |
updated_at
The time the milestone was last updated. |
iid
The IID of the milestone. |
project_id
The ID of the project the milestone is associated with. Reference: |
title
The title of the milestone. |
description
The description of the milestone. |
due_date
The date the milestone is due by. |
start_date
The start date of the milestone. |
state
The state of the milestone. Possible values are |
created_at
The time the milestone was created. |
projects
Replication Method : |
Key-based Incremental |
Replication Key |
last_activity_at |
Primary Key |
id |
API endpoint : |
The projects
table contains info about specific projects.
id
The project ID. Reference: |
||||||
last_activity_at
The time of the last activity associated with the project. |
||||||
approvals_before_merge
The number of users who should approve merge requests by default. |
||||||
archived
Indicates if the project has been archived. |
||||||
avatar_url
The URL of the avatar associated with the project. |
||||||
builds_enabled
Indicates if build are enabled for the project. |
||||||
container_registry_enabled
Indicates if the container registry is enabled for the project. |
||||||
created_at
The time the project was created. |
||||||
creator_id
The ID of the user who created the project. Reference: |
||||||
default_branch
The name of the project’s default branch. |
||||||
description
The project’s description. |
||||||
forks_count
The total number of forks associated with the project. |
||||||
http_url_to_repo
The |
||||||
issues_enabled
Indicates if issues are enabled for the project. |
||||||
lfs_enabled
Indicates if LFS is enabled for the project. |
||||||
merge_requests_enabled
Indicates if merge requests are enabled for the project. |
||||||
name
The name of the project. |
||||||
name_with_namespace
The namespace of the project and the project name, e.g. |
||||||
namespace
Details about the namespace the project is associated with.
|
||||||
only_allow_merge_if_all_discussions_are_resolved
Indicates if merge requests can only be merged when all discussions are resolved. |
||||||
only_allow_merge_if_build_succeeds
Indicates if merges are allowed only if builds succeed. |
||||||
open_issues_count
The total number of open issues. |
||||||
owner_id
The ID of the project’s owner. |
||||||
path
The path of the project. |
||||||
path_with_namespace
The project’s path with the namespace, e.g. |
||||||
permissions
Details about the group and project-level permissions associated with the project.
|
||||||
public
Indicates if the project is public. |
||||||
public_builds
Indicates if builds are public for the project. |
||||||
request_access_enabled
Indicates if request access is enabled. |
||||||
shared_runners_enabled
Indicates if shared runners are enabled for the project. |
||||||
shared_with_groups
Details about groups the project has been shared with. |
||||||
snippets_enabled
Indicates if snippets are enabled for the project. |
||||||
ssh_url_to_repo
The SSH URL of the project’s repository. |
||||||
star_count
The total number of stars for the project. |
||||||
tag_list
A list of tags applied to the project. |
||||||
visibility_level
The visibility level for the project. |
||||||
web_url
The URL of the project. |
||||||
wiki_enabled
Indicates if the wiki is enabled for the project. |
Replication Method : |
Full Table |
Primary Key |
id |
API endpoint : |
The users
table contains info about the users in your GitLab account.
id
The user ID. Reference: |
username
The user’s username. |
name
The user’s name. |
state
The user’s current state. Ex: |
avatar_url
The URL of the user’s avatar. |
web_url
The URL of the user’s profile. |
Related | Troubleshooting |
Questions? Feedback?
Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.