Supercharge your GitLab CI Pipelines with OpsLevel's reusable pipeline integration

At OpsLevel, we are platform engineers building for platform engineers.

That means we don’t just think about tools from an implementation standpoint—we also obsess over the developer experience. Because we live and breathe service ownership and automation ourselves, we’re able to discover powerful features, and create solutions that are both technically elegant and incredibly practical.

One of the best examples of this is our GitLab CI integration for deploy reporting. By deeply understanding both how GitLab CI works and how engineers want it to work, we built a solution that uses lesser-known features—like reusable pipelines with dynamic inputs—to make deploy reporting as simple and scalable as possible.

One customer put it best:

"I learned new GitLab CI pipeline techniques from OpsLevel, like dynamic jobs, allowing me to replace my existing pipelines and templates."

Let’s break down what they meant—and why reusable pipelines might be one of the best GitLab CI features you haven’t used yet.

What Are Reusable Pipelines?

GitLab introduced reusable configuration to make CI/CD more modular. Instead of copying-and-pasting YAML blocks across projects, you can now create pipeline templates with inputs and share them across repositories.

Think of it as defining a parameterized job template—like a function—and calling it from your actual pipeline.

Here’s how our integration uses it:

include:
  - project: 'opslevel/report-deploy-gitlab-ci'
    ref: v0.1.5
    file: '/report-deploy.gitlab-ci.yml'
    inputs:
      job-stage: deploy
      needs:
        - deploy-job-1
        - deploy-job-2
      rules:
        - if: $CI_MERGE_REQUEST_IID || $CI_COMMIT_BRANCH == "main"
          allow_failure: true
      name: prod-env-1
      retry: 3
      description: this deploy event was reported by the OpsLevel GitLab CI reusable pipeline!
      environment: production
      integration_url: $YOUR_MASKED_TOKEN_IN_GITLAB
      service_alias: my_service

Why This Matters

This single include block triggers a whole deploy-reporting pipeline from another project. But what makes this particularly powerful are the inputs, which allow you to customize:

• When the pipeline runs (rules)
• Where it runs in the lifecycle (job-stage, needs)
• How it's named and retried (name, retry)
• What data it sends to OpsLevel (e.g. environment, service_alias, description)
  
  

It’s flexible, readable, and reusable—removing duplication and improving maintainability.

Hidden Power: Inputs, Rules, and Conditions

Most GitLab CI users know about .gitlab-ci.yml, but fewer realize you can parameterize included templates and pass in job-level context. With rules and needs as inputs, you get dynamic pipeline behavior without hardcoding logic into every downstream project.

These tools helped our customers adopt better CI/CD hygiene without writing custom scripts or maintaining brittle templates.

The Result: Speed & Maturity

With just a few lines in their .gitlab-ci.yml, any GitLab project can now report deploys to OpsLevel automatically—and do it using modern, modular CI best practices.

Try It Yourself

Want to simplify deploy reporting and get more out of GitLab CI? Check out our GitLab CI deploy report integration and see how reusable pipelines can transform your workflow.