## Summary GitLab's new Events Platform now uses the industry-standard `CloudEvents` specification as the backbone for its EventStore, giving you a more reliable and interoperable foundation for automating workflows triggered by activity in your projects. This means you can expect richer, more consistent automation — like automatically triggering code reviews or other flows when merge request events occur — with built-in observability so the platform stays transparent and debuggable as it scales. --- In the first phase of the GitLab Events Platform, we need to use the EventStore as a Backend That means when we publish an event like this ``` Gitlab::Kas::Events.publish( topic: 'gitlab.issues', event: CloudEvent.new( specversion: '1.0', type: 'com.gitlab.issues.created', source: "/projects/#{issue.project_id}", id: SecureRandom.uuid, time: Time.current.iso8601, datacontenttype: 'application/json', data: { issue_id: issue.id, project_id: issue.project_id, namespace_id: issue.project.namespace_id, author_id: issue.author_id, issue_type: issue.issue_type, created_at: issue.created_at }, gitlab_user_id: current_user.id, # Extension attribute for auth gitlab_user_username: current_user.username, gitlab_organization_id: issue.project.organization_id ) ) ``` This has to be consumed by a **Flow Triggers Worker** within the same instance of the App using the current implementation of the EventStore {width=900 height=417}