We need to provide value back to our customers and make [scheduled triage](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/scheduled/index.md) work out of the box and easy to configure. ## Goal * Allow easy out of the box configuration of scheduled triage policies per project / group. * Configuration YAML file that can be defined at the project or group level. * The definition should ideally be shared with https://gitlab.com/groups/gitlab-org/-/epics/7486, with a different `policy_type: scheduled`. * Dogfood this in our own process (replace https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/scheduled/index.md with the native feature over time). * Sunset https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/scheduled/index.md after the building all the capabilities into GitLab. ## Proposals 1. Just use `gitlab-triage` as a gem and we still maintain it as an external tool. Advantages: 1. People can have policy files which can target more than one GitLab instances, assuming we're still using the API as the data source 1. We're also one of the API consumers which can benefit the development of API 1. We keep backward compatibility, and evolve as we go. We can move both ways at the same time, much less risk 1. Absorb `gitlab-triage` and sun set this gem. For example, if we can use all the optimized `Finder` in GitLab, why do we need to use the API, which is certainly slower and more complex? Advantages: 1. Much more performant with internal database access 1. Open up a bunch more potential usages because now we can access EVERYTHING, not just depend on the API development which can drag us back ### Conversations * https://gitlab.com/gitlab-org/gitlab-triage/issues/14#note_41293856 > Then, in the future, we could build a UI to generate the YAML, and/or make the scheduled pipeline creation automatic/hidden instead of having to create it manually. * https://docs.google.com/document/d/1QxRQRLP-GpiCis4oFvm0NLm1lJm6WcTP2rcYfn6RC-Y/edit#heading=h.wb9j4d3aevmg > For an MVP, we could maybe just take `.triage-policies.yml` like we take `.gitlab-ci.yml` and allow people to set scheduled pipelines for that. We still need to think about how to let them specify the schedule though. Perhaps we could extend the UI from scheduled pipelines. For example, add a checkbox to tick that it’s a policy schedule or not. If it’s not, it’s a regular pipeline looking at `.gitlab-ci.yml`. If it’s a policy schedule, then look at `.triage-policies.yml` and create the pipeline for it (without looking at `.gitlab-ci.yml`) Actually, this doesn’t sound trivial already. We probably want: > > 0. A way to generate a pipeline based on a dynamically generated `.gitlab-ci.yml` > 0. A way to specialize a scheduled pipeline, which can use the above feature to trigger a pipeline * https://gitlab.com/gitlab-org/gitlab-triage/issues/14#note_124322029 > can we have a dedicated page per project, and you just have a bunch of buttons on that page where you click to execute the scripts and it performs the data changes on the issues in that project. Things can be hardcoded at the beginning. That’s okay. We just have to document that we are porting this functionality into GitLab and it may not work 100% for all users.