GitLab
Askel connects to your customer's GitLab instance and lets your product manage merge requests, issues, and CI/CD pipelines in the repositories and groups that their engineering teams own.
What you can do
Create and update issues
Insert issues with a title, description, labels, milestone, and assignees. Update any of those fields on existing issues by issue IID.
Open and review merge requests
Create merge requests from a source to a target branch, or read existing MR details including approvals, pipeline status, and diff stats.
Trigger and monitor CI/CD pipelines
Create a pipeline on a specific branch using a trigger token, then poll the pipelines endpoint for status updates until the run completes or fails.
Read repository file content
Fetch file content from a project repository at any ref using the repository files endpoint, useful for reading configuration files or deployment manifests.
Post comments on issues and MRs
Add notes to issues or merge request threads, useful for posting automated review comments or status updates from your product.
Receive webhook events
Register project webhooks for push, pipeline, merge request, and issue events. Askel routes incoming payloads to your workflow logic.
Opening a GitLab issue when a security scan finds a critical vulnerability
You sell a security posture management tool. Ironclad Systems runs all code on GitLab. When your product identifies a critical vulnerability in a dependency, it should automatically open a GitLab issue in the affected repository, tagged with the correct label and assigned to the repository owner.
- 1
Generate a Personal Access Token
Ironclad's GitLab admin navigates to Profile, then Access Tokens, creates a token with api scope, and pastes it into your product's integration settings.
- 2
Discover projects and groups
Askel calls the GitLab projects endpoint to list repositories Ironclad's token can access. Your team configures a mapping from your product's service names to GitLab project IDs.
- 3
Create the issue
When a critical vulnerability is detected, your product triggers the workflow. Askel calls the issues endpoint with the vulnerability name as the title, a formatted description with CVE details, and the security label.
- 4
Assign to the right engineer
Your product looks up the repository's owner from an internal mapping. Askel sets the assignee_ids field on the issue so the right engineer is immediately notified.
- 5
Write back the issue URL
Askel returns the issue web URL to your product, which stores it on the vulnerability record. Your security team can navigate directly from the finding to the GitLab issue.
API token
The customer's GitLab user navigates to Profile Preferences, then Access Tokens, and creates a Personal Access Token with at minimum the api scope for read and write operations, or read_api for read-only. Askel stores the token securely. For GitLab.com and self-managed instances, the same token format is used; the base URL is configured per customer.
How Askel sits between your product and the customer's system
FAQ for GitLab
Does this work with self-managed GitLab as well as GitLab.com?+
What scopes are needed on the Personal Access Token?+
Can we work with GitLab groups as well as individual projects?+
What happens if the customer archives a project?+
catching drift before it breaks, and hitting go-live dates.
© 2025 Askel.ai. All rights reserved.