GitLab Integration
Push defects to GitLab Issues, sync status, and maintain traceability between TestKase and GitLab.
Overview
The GitLab integration for defects allows you to push defects from TestKase directly to GitLab as new issues. When a defect is pushed, a bidirectional link is established so you can navigate between the TestKase defect and the GitLab issue. Status and priority updates sync between both systems automatically.
Prerequisites
Before pushing defects to GitLab, you must have the GitLab integration connected to your TestKase project. If you have not set it up yet, follow the GitLab Integration setup guide.
You will need:
- An active GitLab integration connection in your TestKase project settings.
- A GitLab Personal Access Token with
apiscope. - Project Admin or Owner role in TestKase, or the appropriate permissions to create defects and use integrations.
Push a Defect to GitLab
When you discover a defect and want to create a corresponding GitLab issue:
- Open the defect in TestKase from the defects list.
- Click the Push to GitLab button in the defect detail view.
- TestKase creates a new issue in your connected GitLab project with the defect details.
- A bidirectional link is established -- the TestKase defect shows a clickable link to the GitLab issue, and the GitLab issue description includes a reference back to TestKase.
Push During Test Execution
The most efficient workflow is to push defects during test execution:
- Execute a test case in a test cycle.
- When a test fails, create a defect directly from the execution view.
- The defect is automatically linked to the failed test case.
- Click Push to GitLab to immediately create the GitLab issue.
Bidirectional Sync
Once a defect is pushed to GitLab, changes are synchronized between both systems:
- Status updates -- When the GitLab issue is closed or reopened, the defect status in TestKase updates automatically. Similarly, status changes in TestKase are reflected in GitLab.
- Labels -- Priority labels are applied to the GitLab issue and kept in sync.
- Comments -- Comments added on the GitLab issue appear on the TestKase defect, and vice versa.
Field Mapping
TestKase automatically maps defect fields to GitLab issue fields when pushing:
| TestKase Defect Field | GitLab Issue Field | Notes |
|---|---|---|
| Title | Title | Mapped directly |
| Description | Description | Includes a link back to the TestKase defect |
| Priority | Labels | Mapped to priority labels (see table below) |
| Status | State | Open/In-Progress maps to opened, Closed/Achieved maps to closed |
Priority Mapping
| TestKase Defect Priority | GitLab Label |
|---|---|
| Blocker | priority::critical |
| Critical | priority::high |
| Major | priority::medium |
| Minor | priority::low |
| Trivial | priority::low |
If the priority labels do not exist in your GitLab project, TestKase will create them automatically when the first defect is pushed.
Viewing Pushed Defects
After a defect is pushed to GitLab, the defect detail view in TestKase displays:
- A GitLab badge with the issue IID (e.g., #45). Clicking the badge opens the GitLab issue in a new tab.
- The current sync status.
From the GitLab side, the created issue includes:
- The defect title as the issue title.
- The defect description with a link back to TestKase.
- Priority labels applied automatically.
Troubleshooting
▶Pushed defect is not appearing in GitLab
Ensure the token user has at least Reporter role on the GitLab project (Developer or higher
is recommended). Verify your token has the api scope and the instance URL is correct.
▶Priority labels are not being applied
TestKase creates priority labels automatically. If your GitLab project has restrictions on label creation, create the labels manually in your project settings.
▶Does disconnecting delete pushed defects from GitLab?
No. Disconnecting only removes the integration link in TestKase. Issues created in GitLab via defect push remain in the project regardless of the TestKase integration status.