Gitlab Hooks
Problem to solve
GitLab has a number of features, currently online (.gitlab-ci) and planned (gitlab-triage &636) that essentially represent user workflows run via triggered events and configured by software development teams. It might be interesting to consider a general workflow and triggering architecture for gitlab events rather than simply building a series of one off features with unique quirks, bugs, and conceptual models.
From the original discussion
It seems to me, and maybe this is my love of emergent design, like perhaps there is a broader feature there than
.triage-policys.yaml. If you think about it.gitlab-ci.yamlis a workflow that is trigger on commit (filtered through rules) or on a schedule (which is actually a bit annoying as my scheduled jobs and ci jobs often aren't really the same and could import each other if they were).
Intended users
My expectation is such a platform would first be leveraged by GitLab engineers themselves to enable features such as triage but ultimately I'd expect usage by Delaney and Devon, with other Personas possibly feeding in new requirements.
User experience goal
Users should be able to integrate with gitlab events other than simply push and create MR using the rich and robust language for workflows that gitlab-ci represents.
Proposal
What if and this is perhaps the bad idea, spitball, first pass but, what if, these just registered as event listeners somewhere like .gitlab/hooks/ and then in that folder I could drop a yaml file matching ci syntax with a say a filter that specified which object should trigger the workflow.
I suspect teams would invent all kinds of ways to use that you never imagined
Further details
Permissions and Security
Permissions here are really interesting to think about since they inherit from the repository permission model. Probably that's fine, it works for the gitlab-ci file after all but it might drive adoption of code owners