-
Notifications
You must be signed in to change notification settings - Fork 442
Events
The OBS has a pub/sub event system built in.
OBS sub-systems publish events and other OBS sub-systems then react to published events.
Event
s describe something that happened throughout the OBS (backend and frontend). Things like
- The build of package FOO in project BAR has failed
- The submit request #12345 was accepted
- A comment was created in project FOO
See Event::Base
and classes inheriting from it (e.g. Event::CommentForProject
or Event::RequestStatechange
).
We publish an event by creating an instance of Event
in the database. The code below will, for instance, create an event that describes that a the package obs-server
was branched by the user henne
.
Event::BranchCommand.create(project: 'OBS:Server:Unstable',
package: 'obs-server',
targetproject: 'home:henne',
targetpackage: 'obs-server',
user: 'henne')
Throughout the app, Event
instances get created by:
- code like above
- the OBS backend
Most of the events happen in the OBS backend. It exposes them on its /lastnotifications
API. We poll this API periodically (via clockwork
) with the UpdateNotificationEvents
class. That class then creates instances of Event
in the database.
There are several subsystems that subscribe to the publishing of events and then do something.
- The Notifications sub-system is notifying people about events. This sub-system is triggered by many of the events.
- An
ActiveJob
is filling the ProjectLog with entries based on events. This job is scheduled by many of the events. - Another
ActiveJob
keeps The-BackendPackage-Cache fresh. This job is scheduled by commit and service events. - The
UpdateReleasedBinariesJob
ActiveJob
tracks published packages. This job is scheduled by packtrack events. - The
RabbitmqBus
. This sub-system is triggered by many of the events. See below.
Many events are also published on the RabbitMQ message bus when they happen.
Event
classes that respond to the the message_bus_routing_key
method are send to the obs
exchange. Event
classes that respond to the method metric_fields
are send to the metrics
exchange.
The CleanupEvents
job destroys all the Event
instances where the other subs-systems have done their job. This state is tracked in the Event
instance.
Jobs that inherit from CreateJob
increase the Event.undone_jobs
attribute by 1 if they are scheduled. And subtract Event.undone_jobs
attribute by 1 if they are finished. SendEventEmailsJob
sets Event.mails_sent
to true
once it finishes.
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Repository
- Data Migrations
- next_rails
- Ruby Update
- Rails Profiling
- Installing a local LDAP-server
- Remote Pairing Setup Guide
- Factory Dashboard
- osc
- Setup an OBS Development Environment on macOS
- Run OpenQA smoketest locally
- Responsive Guidelines
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models