Connect GitLab

GitLab plays two roles in the demo: catalog source (covered by Ocean ingestion) and pipeline executor — the Deploy Stack (GitLab CI) workflow creates real pipelines in GitLab projects and tracks them to completion. This page sets up the pipeline side.

1. Access token

The IDP backend needs a GitLab token with api scope on your group to create pipelines:

services:
  backend:
    environment:
      - GITLAB_ACCESS_TOKEN=glpat-...
      - GITLAB_WEBHOOK_SECRET=<random string, used to validate webhooks>

2. Pipeline webhooks (per project)

For each GitLab project a workflow will deploy, add a webhook so the IDP learns immediately when pipelines finish:

Project → Settings → Webhooks:

• URL: https://<your-idp-domain>/api/v1/gitlab/webhook
• Secret token: the same GITLAB_WEBHOOK_SECRET as above
• Trigger: ✅ Pipeline events

3. Allow pipeline variables ⚠️

The IDP passes inputs to pipelines as pipeline variables (DEPLOY_ENV, DEPLOY_VERSION, IDP_RUN_ID). Since GitLab 17, creating a pipeline with variables via API returns 403 unless the project allows it.

For each project, set the minimum role to Developer:

Project → Settings → CI/CD → Variables → Minimum role to use pipeline variables → Developer

or via API:

curl -X PUT "https://gitlab.com/api/v4/projects/<project-id>" \
  -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  -d "ci_pipeline_variables_minimum_override_role=developer"

The demo applies this to its 4 pipeline projects (orders-service, payments-service, analytics-pipeline, frontend-webapp).

4. Verify

You'll fully verify this in Part 3 (add the CI job) and Part 5 (run the workflow). The quick smoke test:

curl -X POST "https://gitlab.com/api/v4/projects/<project-id>/pipeline" \
  -H "PRIVATE-TOKEN: $GITLAB_TOKEN" -H "Content-Type: application/json" \
  -d '{"ref":"main","variables":[{"key":"IDP_RUN_ID","value":"test"}]}'

A 201 response with a pipeline URL means token + variable settings are correct.

Next: model your catalog with blueprints →