Automate Project Management with Rudder CLI and GitLab CI/CD Beta

This guide shows how to run the same validate and apply workflow you use locally inside a GitLab pipeline.

Prerequisites

• A GitLab project with your Rudder CLI YAML project checked in
• A workspace-level Service Access Token with permissions for the resources you manage (see Import Workspace Resources for a full permission matrix)
• If you’re on Free or self-hosted plan, or for testing and development only: A Personal Access Token with Read-Write role — see Import Workspace Resources for token types and caveats
• Store the token as a masked CI/CD variable (for example RUDDERSTACK_ACCESS_TOKEN)

Example pipeline

The following .gitlab-ci.yml sketches a two-stage flow: validate on every branch, apply only on the default branch after validation succeeds. Adjust image, paths, and branch rules to match your environment.

stages:
  - validate
  - apply

variables:
  RUDDER_PROJECT_PATH: "$CI_PROJECT_DIR/my-rudder-project"

validate:
  stage: validate
  image: rudderlabs/rudder-cli
  script:
    - rudder-cli validate -l "$RUDDER_PROJECT_PATH"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH

apply:
  stage: apply
  image: rudderlabs/rudder-cli
  script:
    - rudder-cli apply -l "$RUDDER_PROJECT_PATH" --dry-run
    - rudder-cli apply -l "$RUDDER_PROJECT_PATH"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  needs: ["validate"]

Use the official CLI image only if it matches the version you run locally. Alternatively install the binary in the job (for example from GitHub releases) so versions stay aligned with Install Rudder CLI.

See more

• GitHub Actions for Rudder CLI for the maintained GitHub Action and workflow patterns
• Commands Reference for core rudder-cli commands and subcommands