<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=296630) </details> <!--IssueSummary end--> <!--This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!--Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues.--> <!--Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.--> Currently, pipelines can only be triggered on a schedule using the UI (CI/CD -\> Schedules), or REST API. Ideally, it should be possible to define schedules in the `.gitlab-ci.yml` file. This has several benefits, but most importantly, we can use a single schedule definition and share it with other projects using `include`. This also complies with our policies to define (as much as possible) "as code". See: https://support.gitlab.com/hc/en-us/requests/182472 ## Intended users * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#devon-devops-engineer) ## Proposal ### Option A : In `.gitlab-ci.yml` (keeps all CI/CD config in one place) Add a new top-level `schedules` keyword that allows defining multiple schedules directly from code. Proposed syntax: ```yaml schedules: - name: Schedule name cron: * * * * * timezone: UTC # could come in future iteration target_branch: main variables: {} # could come in future iteration ``` Required fields: * `name` * `cron` Field with defaults values: * `timezone`: Defaults to `UTC` * `target_branch`: Defaults to `CI_DEFAULT_BRANCH` * `variables`: Defaults to an empty block `{}` ### Option B : Separate `.gitlab-pipeline-schedule.yml` file yaml `# .gitlab/schedules.yml (on default branch) schedules: - name: "Nightly build" cron: "0 2 * * *" ref: main variables: ENVIRONMENT: production` ### Design ideas/questions * Which option is the preferred configuration approach? * Which takes precedence in case of conflict between `schedules` block in the `gitlab-ci.yml`, schedules in UI or defined through the API? The last schedule change takes precedence