### Release notes 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 to the compliance and security 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) ### Problem to solve Allow for another approach to non-conflicting enforcement of custom CI and security scans. Common use cases include: * Enforcing scans to meet security and compliance controls on a regular cadence (generally targeting default branch). * Checking project configurations ### Intended users ### User experience goal ### Proposal For design and details, please [check the design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/499554) for SSOT <details> <summary> Original proposal 1. Introduce a new condition within the pipeline execution policy for enforcing custom CI through a scheduled pipeline, which is additive within downstream projects to any existing scheduled pipelines. 2. Provide a limited set of options for defining the cadence. 3. Ensure that jobs can start around a defined date and time, but that jobs are distributed across a time window and not executed all at once. </summary> <table> <tr> <th>Select a condition</th> <th>Complete condition and action (weekly)</th> </tr> <tr> <td> {width="797" height="552"} </td> <td>  </td> </tr> <tr> <td> * If the user completes the action first, as it's organized today, they may provide inputs that will not work with the Scheduled condition. If they use the Triggered condition, they can specify conditions in the remote file itself in granularity. * Additionally, it's possible some rules defined in a remote file may not work well with scheduled pipelines. * With this proposal, the user can first determine which type of policy they want and then clearly define jobs that are suitable. </td> <td> * In the 2nd step, the options for the scheduled condition appear once the user selected "Enforce jobs in a scheduled pipeline". * The options allow for a limited set of options for a "cadence" which we can also expand up on in the future as needed. * The other selections are the same as we have in SEP for the condition. * For the action, as the option in the previous step was to enforce a scheduled pipeline, we'd only have this one option that maps to the YAML for `scheduled_only`. This will mean that a new scheduled pipeline will be created in the project and this will run the jobs defined in the associated `pipeline-execution.yml`. * Any existing scheduled pipelines in the project would be unaffected. There could be additional opportunity in the future for an "Override" mode which could be surfaced as another selection option, which could be used to enforce some behavior for existing scheduled pipelines. * We can set a limit or warn users in the UI to guide them on the minimum span of time they can distribute the jobs, to ensure optimal use of resources. </td> </tr> </table> ### <table> <tr> <th>Daily schedule options</th> <th>Monthly schedule options</th> </tr> <tr> <td>  </td> <td>  </td> </tr> <tr> <td> * Options vary if you select daily, weekly, or monthly - here's daily </td> <td> * For Monthly, start from day of month with a numeric value, e.g. the 1st day of each month through to the 28th. </td> </tr> </table> <table> <tr> <th>Monthly schedule for container agents</th> </tr> <tr> <td> {width="844" height="489"} </td> </tr> <tr> <td> * Similar to scan execution policies, we'll need to further consider as well the option to enforce container scans through container agents. </td> </tr> </table> :frame_photo: [See this in FigJam...](https://www.figma.com/board/SI0lyKm8DpKmSksvhgG9cm/Scheduled-pipeline-enforcement?node-id=1-155&t=w55IU6t8l0AEBZoI-4) ### Further details </details> ### Permissions and Security ### Documentation ### Availability & Testing ### Available Tier ### Feature Usage Metrics ### What does success look like, and how can we measure that? ### What is the type of buyer? ### Is this a cross-stage feature? ### What is the competitive advantage or differentiation for this feature? ### Links / references <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._ <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._ <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION-->