GitLab Automations
Given we have the entire lifecycle represented in GitLab, we have a unique opportunity to create workflows that do everything you want, out of the box. But with millions of users, come millions of different use cases. Our tool is flexible enough to work for most of those, but it doesn't take the work out of the hands of the users in all cases.
To further reduce cycle time, we can make it easier for users to automate parts of their workflow. Either to save time, or just to make lives easier.
This would also allow you to essentially automate and fully work from within your issue board.
## Current Status
This is on our 12-18 month roadmap. It's currently awaiting ~"workflow::design" and ~"workflow::solution validation" (https://gitlab.com/gitlab-org/gitlab/-/issues/344136+).
In the interim, we recommend exploring https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage as a potential work around.
## Proposal
Allow users to create automations based on events in GitLab.
Automations look like this:
`If X, do Y`
__X__ relates to events emitted within GitLab. For example, a merge request is merged or an issue gets a particular label.
__Y__ relates to actions with GitLab. E.g. a label is applied to an issue or MR, or a particular comment is added to an issue or a particular pipeline or job is ran.
### Events
Events would have a few fields, e.g.:
- action: label added
- subject: issue#22331
- object: ~pizza
- namespace: gitlab-org/gitlab-ce
### Event bus
There'd be a single event bus with events scoped per namespace*.
We'd write hooks in the code for things we want the user to be able to act on. Initially this could be only simple things like: `issue created` `issue closed`, `merged to master` etc, but it'd be fairly easy to quickly expand on this.
* (initially per project, but I can imagine wanting to act on events on group level)
### Actions
Actions can be almost anything, but initially we could focus on things that are not possible to automate today. Such as label actions (add/remove labels).
## MVC
An MVC could be:
- events: issue created, issue closed, label added to issue
- actions: add label to issue, remove label
Creating an automation would look like:
`On [event] do [action]`
Where [event] would have to allow you to choose a label or issue state.
## Future iterations
Future iterations would allow you to:
- add AND clauses to actions
- filter down further to specific events
- add more actions
- add more events
- have a webhook as an action
Given the nature of the proposal, this should be easy to expand on by the OS community.
epic