Skip to content

API for Stopping and Snoozing Scheduled Pipeline Execution Policies

Problem Statement

Users of GitLab Scheduled Pipeline Execution Policies need a way to temporarily pause pipeline executions during critical periods or maintenance windows. Otherwise, they must either disable the entire policy or manually manage schedules, which is inefficient and error-prone.

Business Value

  • Improved resource management for CI/CD infrastructure
  • Reduced operational overhead during maintenance windows
  • Prevention of resource contention between scheduled scans and critical deployments
  • More efficient cost management of CI minutes and runner resources

User Story

As a DevOps engineer or security team member,
I want to temporarily pause scheduled pipeline executions for specific policies,
So that I can free up CI/CD resources for critical operations and manage costs effectively.

Requirements

Core Functionality

  1. Allow users to temporarily pause scheduled pipeline executions:

    • Specify snooze duration
    • Document reason for snoozing (optional)
    • Cancel currently running scheduled pipelines
    • Prevent new scheduled pipeline executions during snooze period
    • Auto-resume after snooze period ends
  2. GraphQL API implementation:

    • Mutation to snooze policy executions
    • Query to check snooze status
    • Proper error handling
    • Authorization checks
  3. UI/YAML Changes:

    • Add snooze controls to policy management interface
    • Display current snooze status and remaining duration
    • Option to end snooze period early
pipeline_execution_schedule_policy:
- name: "Scheduled PEP"
  enabled: true
  content:
    include:
    - project: path/to/project
      file: policy-ci.yml
  schedules:
  - type: daily
    start_time: "00:00"
    time_window:
      distribution: random
      value: 3600
    timezone: "America/New_York"
    snooze:
      reason: "Too many pipelines"
      until: "2025-06-26T16:27:00+00:00"
  1. Audit & Monitoring:
    • Track who initiated snooze actions and why
    • Log affected pipelines
    • Basic metrics for monitoring

Authorization

  • Require appropriate permissions (maintainer/owner)
  • Support both group and project-level policies
  • Follow GitLab's permission model

Out of Scope

  • Bulk snooze operations across multiple policies
  • Scheduled resume times
  • Auto-snooze based on resource utilization
  • Integration with incident management

Rollout

  • Feature flag protected
  • Progressive enablement starting with GitLab.com
  • Monitor for performance impact and user feedback
Edited by Andy Schoenen