GitLab CI Integration

Overview

CI Sizer supports GitLab CI through the gitlab-webhook-edge-connect component — a Kubernetes MutatingAdmissionWebhook that intercepts GitLab Runner executor pods and injects the CI Sizer collector sidecar.

Unlike Forgejo/GitHub Actions (which use GARM for runner lifecycle management), GitLab Runner uses its own Kubernetes executor. The webhook intercepts pods at admission time and mutates them to include the collector.

Repository: edp.buildth.ing/DevFW-CICD/gitlab-webhook-edge-connect

Architecture

┌──────────────────────────────────────────────────────────────────┐
│  Kubernetes API Server                                           │
│                                                                  │
│  MutatingAdmissionWebhook                                        │
│  ┌────────────────────────────────────┐                          │
│  │ gitlab-webhook-edge-connect        │                          │
│  │                                    │                          │
│  │  Intercepts pods with label:       │                          │
│  │  job.runner.gitlab.com/pod (Exists)│                          │
│  │                                    │                          │
│  │  Injects: collector sidecar        │                          │
│  │  Sets: shareProcessNamespace=true  │                          │
│  └────────────────────────────────────┘                          │
└──────────────────────────────────────────────────────────────────┘

Pod Targeting

The webhook targets GitLab Runner pods using a label selector (not annotation):

objectSelector:
  matchExpressions:
    - key: job.runner.gitlab.com/pod
      operator: Exists

This label is automatically applied by the GitLab Runner Kubernetes executor to all job pods.

Backends

The webhook supports two mutation backends:

Collector Injection

The collector is injected using the shared library ci-sizer/pkg/inject, which is common across all CI providers. The injection adds:

• A collector sidecar container
• shareProcessNamespace: true on the pod spec
• Appropriate environment variables for CI context

Cgroup Exclusion Strategy

GitLab Runner pods present a unique challenge: the build container’s process name varies by image (it could be sh, bash, pwsh, or any custom entrypoint). This makes positive identification by process name impossible.

CI Sizer solves this with an exclusion strategy:

1. Map all known containers by process name (e.g., gitlab-runner-helper, collector)
2. Any remaining cgroup paths that don’t match a known container are assigned to the build container

This is configured via:

CGROUP_STRATEGY=exclusion

Run Metadata

Run Index

For GitLab (non-GARM) providers, the run_index is assigned by the receiver using a MaxRunIndex+1 counter per org/repo/workflow combination. This provides sequential run numbering without requiring GARM lifecycle events.

Run URL

The run URL is propagated via the pod annotation job.runner.gitlab.com/url, which the collector reads at startup.

Runner Name

For GitLab, the runner_name is set to the pod name (pod.Name), since GitLab Runner pods are ephemeral and uniquely named per job.

Deployment

The webhook is deployed to the ci-sizer namespace with TLS provided by cert-manager using a self-signed issuer:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gitlab-webhook-tls
  namespace: ci-sizer
spec:
  secretName: gitlab-webhook-tls
  issuerRef:
    name: ci-sizer-selfsigned
    kind: Issuer
  dnsNames:
    - gitlab-webhook-edge-connect.ci-sizer.svc
    - gitlab-webhook-edge-connect.ci-sizer.svc.cluster.local

GitLab-Specific Configuration

For commit status notifications to GitLab, see OOM Detection — Commit Status Notifications.