Discussion: GitLab CI Events - hierarchical events - use cases

Discussion

In this issue we plan to document a dozen of concrete use-cases for GitLab CI Event, especially regarding how we could leverage hierarchical events.

In this issue leave one use-case / example per thread.

Hierarchical events

Hierarchical events is a technique to group related events together, and to make it eventually possible for users to subscribe to a group of events, instead of just one.

Example:

# Hierarchical events subscription 1 - Run a job for all audit events:

audit:
  on: events/audit/*
  script:
    - echo $[[ event.audit.operation_name ]]

# Hierarchical events subscription 2 - Cloud Events:

deploy:
  on: events/cloud/com.gitlab.cells.operator/commands/*
  script:
    - ./deploy --stat $[[ event.command ]]

# Non-hierarchical subscription:

annotate:
  on: issue_created
  script: annotate $[[ event.issue.id ]]

The idea behind hierarchical events is that all events under the same path share same schema fields that can be consumed in a CI/CD job.

References

• Recent meeting: https://docs.google.com/document/d/15zY0eGrARd2i0HSSzHbwdQo233yDIR6rzchcVgV6OfA/edit
• An MR having some discussions: !125106 (closed)
• GitLab CI Events (#363384 - closed)
  • https://docs.gitlab.com/ee/architecture/blueprints/gitlab_ci_events/
• GitLab Events (&8349)
  • https://docs.gitlab.com/ee/architecture/blueprints/gitlab_events_platform/