GitLab tracks the work and runs the CI. Kestra connects it to everything else: file an issue the moment a pipeline fails, raise a merge request when an automated change is ready, trigger GitLab CI on an upstream event, and keep one execution history across the whole chain.
GitLab is the system of record for code, issues, and CI. Kestra connects it to the rest of the stack: the issues.Create and mergerequests.Create tasks file issues and raise MRs from any workflow, and a CI pipeline can be triggered and polled over the GitLab REST API. File an incident issue on failure, open an MR for a generated change, or fire a pipeline when Terraform or dbt finishes, all in one audited flow.
GitLab owns the repo, the issues, and the CI runner. Kestra owns the automation around them: what files an issue, what opens an MR, what triggers a pipeline, and where the cross-tool audit trail lives.
When any flow fails, an errors handler running io.kestra.plugin.gitlab.issues.Create opens a GitLab issue with the execution link, the failing task, and labels. The incident lands in the team's existing tracker without a human relaying it from a Slack alert.
When a flow produces a change, a dependency bump, a regenerated config, a data-driven update, mergerequests.Create opens an MR from a source branch for human review. The automation proposes; a person still approves and merges, so generated changes never skip review.
The plugin covers issues and MRs; GitLab CI is driven over the REST API with io.kestra.plugin.core.http.Request. A flow POSTs to the pipeline trigger endpoint when an upstream step confirms, then polls pipeline status until terminal, so CI fires on the event that matters rather than only on a push.
issues.Search queries a project's issues by state and labels. A scheduled flow can pull open issues, summarize stale or unassigned ones, and post a triage digest to Slack, turning a manual board review into an automated routine.
GitLab actions rarely stand alone. Kestra runs Terraform, then opens an MR with the plan; or runs a dbt build, then files an issue if tests fail. GitLab is one step in a flow that spans the whole toolchain, with one execution ID.
Both tasks accept a custom url and apiPath, so self-managed GitLab behind a corporate network works exactly like GitLab.com. Kestra running inside the same network reaches the private instance without exposing it, which matters for regulated teams.
Patterns platform and DevOps teams run in production today. Each one shows the flow end to end, with the real plugin classes in play.
A monitored flow runs on a schedule. On failure, the errors handler opens a GitLab issue with the execution link and the failing task, and pings Slack. The incident lands in the team's tracker without manual relay.
The issue is created only when the monitored task fails.
The issue body links straight to the failing run.
No human relays the alert from Slack into GitLab.
A scheduled flow regenerates a config or bumps a dependency on a branch, then opens a merge request with mergerequests.Create for human review. The automation proposes the change; a person approves and merges it.
The flow opens the MR; a human still approves and merges.
Nothing skips review just because a flow produced it.
Branches and title are typed flow inputs.
When Terraform or an ingestion step finishes, Kestra POSTs to the GitLab pipeline trigger endpoint over the REST API, then polls pipeline status until terminal. CI fires on the event, not only on a push, and the result branches the flow.
core.http.Request POSTs to the pipeline trigger token endpoint.
A retrying request loop waits for the pipeline to finish.
CI runs when upstream confirms, not only on a Git push.
A daily flow runs issues.Search for open issues, filters stale or unassigned ones, and posts a triage digest to Slack. A manual board review becomes a routine that runs itself.
issues.Search filters the project's issues server-side.
Stale or unassigned issues get flagged automatically.
One scheduled summary instead of constant board-watching.
Kestra runs a Terraform plan, captures the output, and opens a GitLab MR containing the plan for review. Infrastructure changes get the same MR-based review as code, driven from one flow.
The Terraform plan lands in an MR like any code change.
Plan, branch, and MR share one execution ID.
Slack notifies the right people the MR is open.
Thank you Kestra for your great support and for providing a best-in-class platform to power our integrations!
| Capability | | GitLab CI | Jenkins | GitHub Actions |
|---|---|---|---|---|
| File issues from any workflow | issues.Create task | Within CI jobs only | Scripted in jobs | Scripted in jobs |
| Raise MRs from automation | mergerequests.Create task | API scripts in CI | API scripts | API scripts |
| Trigger on non-Git events | Webhook, S3, Kafka, schedule | Pipeline schedules, webhooks | Plugins or polling | Cron or repo events |
| Chain GitLab with Terraform, dbt | Native plugins | Scripted in CI YAML | Scripted in stages | Scripted in steps |
| Approval gate with reviewer logged | Native pause + resume | Manual job + protected env | Input step | Environment approvals |
| Cross-tool execution history | One view across tools | GitLab-scoped | Jenkins-scoped | Actions-scoped |
| Self-hosted, first class | url + apiPath, any instance | Self-managed GitLab | Self-host | Self-hosted runners |
Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.
File issues on failure, raise MRs from automation, trigger CI on any event, and chain GitLab with the rest of your stack. Open source, self-hosted, event-driven.
