## :pen_fountain: Executive Summary Following the introduction of the pipeline execution policy, which allows for enforcing CI jobs/scripts within triggered pipelines, we plan to extend support for scheduled enforcement. Enforce compliance scripts, security scans, or other custom CI within scheduled pipelines enforced within each of your project's pipelines to ensure your requirements are met. Scheduled pipeline enforcement provides another flexible tool in the security and compliance toolbox by enabling enforcement on daily, weekly, or monthly on a cadence. Scheduled pipelines are introduced in a project as additive pipelines and do not inject or enforce jobs in the project's `.gitlab-ci.yml` , rather they can be used to target the default branch and check regularly for dependencies, project configurations, or other requirements. :tv: [Demo](https://www.youtube.com/watch?v=hREfQR_qZiw) #### Engineering Assessment TBD \[Brief description of the engineering assessment of this candidate item.\] #### Dependencies * Team dependencies: \[List team dependencies\] * Epic/Issue dependencies - _Link to dependent epics/issues via the linked items widget below for ease of drill down_ * External dependencies: \[Any external dependencies\] #### DRIs * **PM**: @g.hickman * **EM**: @alan * **UX/PDM**: @tparker1 * **Group(s)**: ~"group::security policies" * **Engineering Owner**: @rvider #### Initiative Driver - Product or Engineering? ~"Interlock Priority::P1" ## :chart_with_upwards_trend: Success Metrics 1. 10 customers adopting/using scheduled pipeline execution policies across 100+ active projects 1 month post GA. 2. 30 customers adopting/using scheduled pipeline execution policies across 100+ active projects 2 months post GA. ## :briefcase: Business Justification More details in [thread](https://gitlab.com/groups/gitlab-org/-/epics/17875#note_2958632012). ## :tools: Core Functionality Requirements 1. **Policy Configuration** - [x] Support for defining scheduled pipeline execution policies via YAML configuration - [x] Support for configuring policies through the UI with feature parity to YAML configuration - [x] Ability to specify schedule intervals (daily, weekly, monthly) - [x] Support for time windows to distribute pipeline executions evenly - [ ] Updated YAML to align with "scheduled pipeline execution policies" terminology. (https://gitlab.com/gitlab-org/gitlab/-/work_items/538299) 2. **Schedule Management** - [x] Reliable execution of scheduled pipelines according to configured intervals - [x] Support for timezone configuration - [x] Ability to specify days of month for monthly schedules - [x] Proper handling of schedule updates when policy configuration changes - [ ] Ability to observe active/previous operations (at minimum at a log level), including counts of active operations/schedules - [ ] Error handling for any failed schedules or dropped schedules - [ ] Dry-run option to trigger a test run against one or more projects/groups and estimate functional and performance impact (https://gitlab.com/groups/gitlab-org/-/work_items/20526) 3. **Branch Targeting** - [ ] Support for targeting protected branches (https://gitlab.com/gitlab-org/gitlab/-/work_items/547933) - [ ] Limit on the number of branches that can be targeted (for performance reasons) 4. **Pipeline Execution** - [x] Ability to run custom CI jobs defined in remote configuration files - [x] Proper isolation from project's existing CI/CD configuration - [x] Support for running on the default/protected branches to check dependencies, project configurations, etc. - [x] Enforce variable precedence - [ ] Support for up to 5 schedules to configure rules more atomically, support testing, or scope conditionally on projects (limit of 1 limits flexibility for more use cases) 5. **Snooze Functionality** - [x] Ability to temporarily pause executed scheduled pipeline executions that have not yet started, as well as active schedules - [x] Support for specifying snooze duration - [x] Auto-resume after snooze period ends 6. Artifact Download * [ ] Artifacts can be downloaded between scheduled policy jobs (https://gitlab.com/gitlab-org/gitlab/-/issues/577916) 7. Bot Access to CI Configs * [ ] Security policy bot can access CI configs without manual permission grants (https://gitlab.com/gitlab-org/gitlab/-/issues/588852) 8. Kill/cancel running schedules in case of emergency (https://gitlab.com/gitlab-org/gitlab/-/issues/560629) * [ ] Define a command/option to cancel any open operations in the case of emergency 9. Audit Events/Logging/Metrics * [ ] Prometheus metrics exposed: unique namespaces, pipeline count, worker duration * [ ] Audit logging for policy changes and executions 10. Cross-repo access (TBD) * [x] Scheduled pipeline execution policy bot cannot read content or trigger other repos -- refinement/discussion ## Performance and Scalability Requirements 1. **Resource Management** - [x] Implement time window distribution to prevent overwhelming CI/CD infrastructure - [x] Support for large groups with many projects (1000+) - [x] Configurable limits to control resource usage 2. **Concurrency Control** - [ ] Prevent too many pipelines from being triggered simultaneously - [ ] Configurable minimum time window based on the number of projects ## Security and Access Control 1. **Permission Model** - [x] Proper access controls for creating and managing scheduled policies - [x] Automatic configuration of security policy project access to CI/CD configuration to ensure stable enforcement/compliance with proper usability 2. **Security Considerations** - [x] Completion of security review and penetration testing - [x] Addressing all security findings from penetration testing ## User Experience 1. **UI/UX** - [x] Intuitive policy creation and editing interface - [x] Clear visualization of scheduled policies in the policy list - [x] Ability to view policy execution status and history - [x] Manual trigger option for testing scheduled policies 2. **Error Handling and Feedback** - [x] Clear error messages for configuration issues - [x] Proper validation of policy configuration - [x] Troubleshooting guidance in documentation ## Monitoring and Observability 1. **Metrics and Logging** - [ ] Track unique namespaces with scheduled pipeline execution policies - [ ] Count of pipelines triggered by scheduled policies - [ ] Performance metrics for worker duration - [ ] Audit logging for policy changes and executions ## Documentation and Support 1. **Documentation** - [x] Comprehensive documentation of feature capabilities and limitations - [x] Clear setup and configuration instructions - [x] Troubleshooting guide - [x] Best practices for scaling and performance ## Integration Requirements 1. **GitLab Ecosystem Integration** - [x] Proper integration with existing pipeline execution policies - [x] Compatibility with other security and compliance features - [x] Support for both self-managed and GitLab.com environments ## :ballot_box_with_check: Acceptance Criteria for GA Release 1. Ensure documented product requirements are addressed 2. Feature is fully functional without requiring feature flags or experimental toggles 3. All identified bugs from experimental phase are resolved 4. Performance testing confirms the feature can handle large-scale deployments 5. Security review is complete with all critical and high issues addressed 6. Documentation is complete and accurate 7. Metrics are in place to track feature usage and performance 8. Customer feedback from experimental phase has been discussed and agreed requirements addressed 9. UI/UX review is complete with all major usability issues addressed 10. Feature has been successfully tested with real-world customer use cases ## Release timeline ~"FY27::Q2"