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

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%

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.

Edited by Viktor Nagy (GitLab)