Quick-start for issue triaging
Details
Problem to solve
As a GitLab instance/group administrator, in order to automate simple, repetitive tasks, I would like to run centrally defined scripts on various GitLab Event hooks
Intended users
- Parker (Product Manager) would like to have issues automatically assigned to him given certain conditions
- Delaney (Development Team Lead) would like to automate an issue workflow
- Sasha (Software Developer) would like to be automatically assigned to issues that he opens an MR for
- Sidney (Systems Administrator) would like to manage automation rules centrally to avoid code duplication and bugs
- Sam (Security Analyst) would like to restrict closing security related issues to his team
Further details
This functionality can already be achieved using webhooks or plugins. We would like to provide a robust infrastructure to improve this use case in terms of:
- processing time
- extendability
- processing costs
Proposal
Design and Format
We can use the serverless.yml
format to define the functions and their triggering events. For this to work, we might need to extend its support to be able to filter events, similarly to Serverless SubscriptionFilter or SNS or CloudWatch logs filtering.
There are some very generic and more specific use cases:
- generic: issue automation. Issue automation means to do an action after an issue/MR has changed.
- specific: workflow automation. Workflow automation means to to an action on a workflow-related event. In case of GitLab these are managed by the
scoped labels
.
Proposed directory structure:
/automation
|- /workflow
| |- label::first
| | |- function1.rb
| | |- function1.js
| |- label::second
| | |- function2.rb
| | |- function2.js
|- serverless.yaml
|- generic-function1.js
|- generic-function1.rb
This would mean that when the scoped label label::first
is applied, then function1.js
and function1.rb
are invoked. The user does not need to write a serverless.yaml
for this, we hide this away from the user.
It allows for iteration too, as we can leave the /workflow
part at first, and just add the basic, serverless.yaml
support first.
Centrally managed
The user of this feature should be able to define its serverless.yaml
at a specific repo, and attach the given repo to the instance/group/project.
In case of project level settings, the scripts could be defined in the project's .gitlab
directory.
Scripts defined at the instance/group level should be accessible at the project level. By default a parent script can be disabled, enabled from a child group or project, and it's event filters can be set without duplicating the code itself. Writing the serverless.yaml
should be enough for these cases. The parent serverless.yaml
should be able to indicate when the given function is not editable
by its children.
e.g at the instance level:
functions:
hello:
handler: handler.hello
events:
- gitlab-issue:
created: true
editable: false
Cloud-agnostic
Where are the above functions run?
We would like to support from the beginning:
- Knative: Knative requires a Kubernetes cluster. This should be provided together with setting the repo.
- AWS Lambda: AWS Lambda could receive the events over AWS SNS. As Serverless+SNS has its own event description already, we would need to wrap to make the setup cloud-agnostic.
GUI
The GUI is not part of this Epic.
We envision pages where the serverless.yaml
is parsed and shown. There might be options to enable/disable functions, or even edit the events that trigger them. These features would alter the serverless.yaml
itself.
Permissions and Security
Documentation
Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
Initial valuation
Problem Statement
How to automate issue-triaging?
Examples:
- auto-assign an issue on creation or on label being applied
- close epic when all issues are closed
- add label based on contents of the comment or the issue description
Reach
6.0 = Impacts a large percentage (~50% to ~80%) of the above.
Impact
1.0 = Medium impact
Confidence
100%
- Q3 System Usability Scale - user feedbacks
- GitLab runs issue triaging too
Effort
Solution idea
- have a few project/group/instance level serverless functions for issue triaging. These would need minor setup using the UI.
- the functions could be enabled / disabled
- functions might have some parameters (e.g. auto-assign issue to user: set the user)
These need a UI.