_Based from [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/361828) where we discussed the initial ideas around this proposal. This epic will encompass all of the development work required across the first iteration to produce a working proof of concept that we can start to rollout and build upon._ ## The goal The goal is to create a unified approach in defining audit events so that they are maintainable and sustainable as audit events become utilized further in our product, and to support increased user adoption. ## The overall solution Similar to how GitLab manages feature flags, we will create a solution that allows us to define every type of audit event with a YAML schema. This collection of YAML files will be the single-source-of-truth for all types of events that can be audited in GitLab. Broadly speaking, the initial MVC will include the following: - The definition of a JSON schema that will form the basis of this work. This JSON schema will include all of the information required to define a new audit event type. - A generation script (similar to `bin/feature-flag`) that will generate compliant YAML files and store them in `config/audit_event/types/{audit_event_type_name}.yaml` - CI linting that checks for: - Compliance to the JSON schema for each new type. - Uniqueness of `name` across all audit event types. - A default-off feature flag that will enforce the use of YAML definitions and raise errors when attempting to audit an event that does not have a definition. - When the flag is disabled, show a deprecation warning. When enabled, raise an error. ## What next? (Next iterations) - We will need to migrate all existing event types to their own definition. We could consider making issues for these available for folks participating n a hackathon. - Use the yaml definition files in `Auditor` to decide whether or not to stream/save to database/save to file when one exists. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->