Trigger and Poll a GitLab CI Pipeline on an Upstream Event

Run a GitLab CI pipeline from an upstream event instead of waiting for a Git push or a fixed schedule. This blueprint lets any system (a data load, an approval, a deploy gate, another flow) start a GitLab CI pipeline over the REST API, then blocks until the pipeline reaches a terminal state and reports the outcome to Slack. It closes the gap between event driven orchestration and GitLab CI, which on its own reacts mainly to commits, tags, and cron rules.

How it works

1. The io.kestra.plugin.core.trigger.Webhook trigger (on_event) exposes a keyed URL that an upstream system POSTs to in order to start the flow.
2. trigger_pipeline (io.kestra.plugin.core.http.Request) POSTs multipart/form-data to /api/v4/projects/{project_id}/trigger/pipeline using a GitLab pipeline trigger token and the chosen ref, creating a new pipeline.
3. wait_for_pipeline (io.kestra.plugin.core.flow.Sequential) wraps the polling logic with a constant retry of PT15S for up to 80 attempts (a 20 minute ceiling).
4. Inside it, check_pipeline GETs /api/v4/projects/{project_id}/pipelines/{id} with the PRIVATE-TOKEN header, and assert_terminal (io.kestra.plugin.core.execution.Assert) fails the block until finished_at is set, which forces the retry to poll again.
5. notify (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts the final pipeline status to Slack, and an errors handler alerts Slack if the trigger or polling fails.

What you get

• Event driven GitLab CI runs that start the moment an upstream step is ready.
• A flow that blocks until the pipeline finishes, so downstream steps can depend on the real result.
• Built in Slack reporting on both success and failure.
• A REST pattern that works on GitLab SaaS and self hosted instances by changing gitlab_url.

Who it's for

• Platform and DevOps engineers wiring CI into broader pipelines.
• Data and MLOps teams that need a build or deploy to run after a job completes.
• Teams replacing brittle webhook glue with declarative, observable orchestration.

Why orchestrate this with Kestra

GitLab CI triggers on commits, tags, merge requests, and schedules. It cannot natively start on an arbitrary upstream business event or wait on it as one step in a larger DAG. Kestra adds an event trigger, retries with a bounded polling window, full execution lineage, and Slack alerting, all in declarative YAML. You get one place to see why a pipeline ran, what it produced, and what happened next.

Prerequisites

A GitLab project with a .gitlab-ci.yml pipeline, and a Slack incoming webhook.

Secrets

• GITLAB_TRIGGER_TOKEN: a GitLab pipeline trigger token (Settings, CI/CD, Pipeline trigger tokens).
• GITLAB_TOKEN: a personal or project access token with api scope, used to read pipeline status.
• GITLAB_CI_WEBHOOK_KEY: key guarding the Kestra webhook trigger.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Set the four secrets above in your Kestra namespace.
2. Pass project_id and ref (and gitlab_url for self hosted GitLab).
3. POST to the webhook URL to start the pipeline, then watch Slack for the result.

How to extend

• Tune the wait_for_pipeline retry block (interval, maxAttempt) for longer pipelines.
• Branch on outputs.check_pipeline.body.status to trigger a rollback or a downstream flow.
• Add variables to formData to pass pipeline variables into GitLab CI.
• Swap the REST calls to target any other CI system that exposes a trigger endpoint.

Links

• Slack plugin docs
• GitLab orchestration with Kestra