GitLab CI Deploy Job

For GitLab-hosted services, the IDP creates a pipeline on the project (via the API, with variables) and tracks it through pipeline webhooks. The deploy job runs only when the pipeline was created by the IDP.

The contract

The IDP creates the pipeline with these variables:

Variable	Meaning
IDP_RUN_ID	the IDP run id — its presence is what activates the deploy job
DEPLOY_ENV	target environment from the self-service form
DEPLOY_VERSION	version from the self-service form

Unlike GitHub, no callback step is needed: the pipeline webhook (configured in Part 1) notifies the IDP when the pipeline finishes.

Full working example — .gitlab-ci.yml

This is the demo's actual CI file (used in idpnextdemo/orders-service, payments-service, analytics-pipeline, frontend-webapp on gitlab.com):

stages:
  - test
  - build
  - deploy

test:
  stage: test
  image: alpine:3.20
  script:
    - echo "Running tests for $CI_PROJECT_NAME"

build:
  stage: build
  image: alpine:3.20
  script:
    - echo "Building $CI_PROJECT_NAME"

deploy:
  stage: deploy
  image: alpine:3.20
  rules:
    - if: '$IDP_RUN_ID'
  script:
    - echo "Deploying $CI_PROJECT_NAME version ${DEPLOY_VERSION:-latest} to ${DEPLOY_ENV:-dev} (IDP run $IDP_RUN_ID)"
    - sleep 20
    - echo "Deployment of ${DEPLOY_VERSION:-latest} to ${DEPLOY_ENV:-dev} complete"

Replace the deploy script with your real deployment commands.

How it works

• rules: - if: '$IDP_RUN_ID' — the deploy job is skipped on normal pushes and merge requests; it only runs in pipelines the IDP created (which always carry IDP_RUN_ID).
• The IDP step succeeds/fails with the pipeline status — a red test or build job fails the deployment step in the run view too.
• Remember the two GitLab project settings from Connect GitLab: the pipeline webhook and ci_pipeline_variables_minimum_override_role=developer — without the latter, pipeline creation 403s.

Next: build the self-service workflows →